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ABSTRACT 


This  work  involves  integrating  the  Army’s  existing  combat  modeling  tool,  JANUS, 
with  the  real-time  three-dimensional  graphics  display  offered  by  NPSNET.  The 
development  of  a  portable  software  package  that  can  create  a  three-dimensional  virtual 
world  from  any  existing  JANUS  terrain  database  is  explained.  In  addition,  a  scripting  tool 
capable  of  rendering  JANUS  scenarios  previously  executed  in  the  traditional  two- 
dimensional  model  is  discussed.  This  replay  capability  allows  the  gamer/analyst  the  ability 
to  watch  the  three-dimensional  battle  unfold  from  any  position  on  the  battlefield.  Lastly, 
the  implementation  of  a  real-time,  networked  link  from  the  two-dimensional  JANUS  model 
to  NPSNET  is  detailed.  This  link  involves  an  Ethernet  connection  from  a  Sun  workstation, 
which  houses  the  two-dimensional  model,  to  a  Silicon  Graphics  workstation  used  for 
rendering  the  real-time  three-dimensional  simulation.  The  methodology  used  and 
techniques  developed  are  fully  portable  to  any  workstation  with  X-windows  capability  and 
any  graphics  workstation  equipped  with  the  GL  libraries. 


CPT  Walter  concentrated  his  efforts  in  the  areas  of  translations  of  JANUS(A)  files  to 
NPSNET  file  foimat  and  the  networking  of  both  JANUS(X)  and  NPSNET.  CPT  Warren’s 
primary  focus  was  on  generating  three-dimensional  terrain  and  the  writing  of  JANUS(A) 
scripts  that  NPSNET  can  read.  Both  CPT  Walter  and  CPT  Warren  worked  together  to 
create  the  tree  and  city  canopies  and  other  cultural  features. 
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1.  INTRODUCTION 


A.  BACKGROUND 

In  a  time  of  shrinking  budgets  and  growing  demands,  the  key  challenge  for  military 
trainers  is  to  find  the  most  effective  and  efficient  use  of  technology  to  supplement 
traditional  instruction.  Motivated  by  this  need,  the  Graphics  and  Video  Laboratory  of  the 
Department  of  Computer  Science  at  the  Naval  Postgraduate  School  is  currently  conducting 
research  on  building  low-cost,  three-dimensional  visual  simulators  on  commercially 
available  graphics  workstations.  The  goal  of  these  simulators  is  the  generation  of  three- 
dimensional  views  of  terrain,  cultural  features  and  vehicles  using  readily  available 
databases.  Current  visual  simulation  efforts  are  on  the  NPSNET  system,  a  networked  visual 
simulator  that  utilizes  SIMNET  databases  and  SIMNET  networking  formats  [ZYDA  91] 
[ZYDA  91a]  [ZYDA  92]  [PRAT  92].  One  of  the  most  recent  research  developments 
underway  includes  the  integration  of  NPSNET  with  the  U.  S.  Army’s  two-dimensional 
combat  model,  JANUS(A). 

B.  MOTIVATION 

In  1991,  the  U.  S.  Army  Training  and  Doctrine  Command  selected  JANUS(A)  as  the 
simulation  software  standard  for  training  at  company  and  platoon  levels,  using  the  battalion 
commander  as  the  senior  trainer.  It  is  also  used  in  a  seminar  role  by  the  Command  and 
General  Staff  College  to  train  new  battalion  and  brigade  commanders  on  the  principles  of 
synchronized  combined  arms  operations  [KANA  91].  JANUS(A)  is  fielded  throughout  the 
world  and,  because  of  its  ability  to  accurately  model  complex  combat  scenarios,  is  widely 
used  by  trainers  and  analysts  in  numerous  applications  which  include  combat  training, 
studies  of  combat  operations,  combat  development,  testing  of  new  equipment,  and  research 
and  development. 

Despite  its  great  success  and  huge  popularity  as  a  combat  development  and  testing 
tool,  JANUS(A)  analysts  and  developers  realized  the  need  for  a  three-dimensional  view  of 
the  battlefield  to  validate  their  results.  An  example  of  this  is  the  new  system  testing  of  the 


1 


M1A2  main  battle  tank  at  Fort  Hunter  Liggett,  California.  As  part  of  this  testing,  the  U.  S. 
Army  TRADOC  Analysis  Command,  Monterey,  used  JANUS(A)  as  a  tool  to  model  the 
operational  testing  of  the  M1A2  tank,  before  it  was  actually  tested  on  the  ground.  A  three- 
dimensional  capability  would  help  validate  this  data  by  verifying  events,  such  as  tank 
positions,  direct  fire  engagements,  and  line  of  sights  between  weapon  systems. 

Also,  because  of  past  virtual  reality  successes,  such  as  SIMNET,  users  knew  that  a 
three-dimensional  view,  in  support  of  J  ANUS(A)  exercises,  would  greatly  enhance  training 
simulations.  Almost  as  good  as  being  on  the  actual  terrain,  a  three-dimensional  world 
would  give  the  gamer/analyst  the  ability  to  watch  the  battle  unfold  from  any  position  on  the 
battlefield.  In  addition  to  standard  scenarios,  this  ability  could  be  used,  in  conjunction  with 
JANUS(A),  for  three-dimensional  ‘after-action  reviews’  at  Combat  Training  Centers,  such 
as  the  National  Training  Center,  Fort  Irwin,  California.  Likewise,  previously  fought  battles, 
such  as  the  famous  ‘Battle  of  73  Easting’,  could  be  reenacted  on  JANUS(A),  and  refought 
in  the  three-dimensional  simulation,  allowing  for  several  ‘what-if’  conditions. 

C.  OBJECTIVES 

The  primary  objective  of  this  work  is  to  produce  a  working  three-dimensional  virtual 
world  that  is  fully  integrated  with  JANUS(A).  To  accomplish  this  objective,  the  goals  were 
threefold:  (1)  create  a  three-dimensional  virtual  world  from  any  existing  JANUS(A)  terrain 
database,  (2)  write  a  scripting  tool  capable  of  rendering  JANUS(A)  scenarios  on  this  three- 
dimensional  terrain  that  were  previously  executed  in  the  traditional  two-dimensional 
model,  and  (3)  implement  a  real-time,  network  link  from  the  two-dimensional  JANUS(A) 
model  to  NFS  NET. 

The  methodology  consisted  of  first  developing  a  two-dimensional  model  to  validate 
both  the  terrain  and  the  script  data  derived  from  JANUS(A),  followed  by  the  integration  of 
JANUS(A)  with  a  fully  functioning  three-dimensional  viewing  capability. 
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D.  CHAPTER  SUMMARY 


Chapter  II  gives  an  overview  of  the  JANUS(A)  system,  including  the  background  of 
its  development,  a  brief  description  of  the  model,  and  the  hardware  necessary  to  run  it.  In 
addition,  this  chapter  discusses  the  many  different  programs  that  are  included  in 
JANUS(A),  followed  by  a  description  of  the  different  data  files,  and  their  relationship  with 
these  programs. 

The  different  hardware  systems  caused  a  data  file  compatibility  problem,  thus 
JANUS(A)  files  were  converted  to  a  format  compatible  with  NPSNET.  Chapter  ID 
describes  the  file  management  system  developed  for  these  converted  files.  It  also  discusses 
the  two-dimensional  replay  model  which  was  developed  to  validate  both  the  converted 
terrain  model  and  the  accuracy  of  the  conversion  utilities. 

Chapter  FV  provides  an  overview  of  NPSNET  and  the  methods  used  to  integrate 
NPSNET  with  the  JANUS(A)  combat  model.  This  includes  a  discussion  of  the  creation  of 
three-dimensional  terrain,  cities,  and  trees. 

One  problem,  when  integrating  the  two-dimensional  model  with  NPSNET,  was  that 
JANUS(A)  does  not  produce  all  of  the  information  necessary  to  define  what  a  vehicle  is 
actually  doing  every  moment  of  the  game.  Chapter  V  describes,  in  detail,  the  expert  system 
used  to  convert  two-dimensional  post-processor  scripts  to  a  three-dimensional  script 

Chapter  VI  describes  the  implementation  of  a  real-time,  network  link  from  the 
recently  developed  Sun-based  version  of  JANUS(A)  to  NPSNET. 

Two  appendices  are  provided.  Appendix  A  describes,  in  detail,  the  method  used  to 
translate  VAX  formatted  files  to  IEEE  format.  Appendix  B  is  a  users  guide  for  the  JANUS- 
3D  program. 


IL  JANUS(A>:  OVERVIEW 


A.  BACKGROUND 

JANUS,  named  for  the  ancient  Roman  god  who  guards  portals,  is  an  interactive, 
computer  based,  war-gaming  simulation  of  combat  operations  conducted  at  the  brigade  and 
lower  level  in  the  United  States  Army  [JANU  86].  The  original  JANUS  simulation  began 
in  the  late  1970’s  at  the  Lawrence  Livermore  National  Laboratory  (LLNL)  to  model 
nuclear  effects,  and  gained  considerable  reputation  for  its  innovative  use  of  graphical  user 
interfaces  [KANA  91].  The  U.  S.  Army  TRADOC  Analysis  Command,  White  Sands 
Missile  Range,  New  Mexico  (TRAC-WSMR),  acquired  this  prototype  from  LLNL  as  a 
result  of  the  JANUS  Acquisition  and  Development  Project,  directed  by  the  U.  S.  Army 
Training  and  Doctrine  Command  (TRADOC)  in  1980  [JANU  86].  In  1983,  TRAC-WSMR 
adopted  JANUS  and  further  developed  it  as  a  high  resolution  simulation  to  support  analysis 
for  Army  combat  developments. 

The  original  version,  developed  at  LLNL  is  known  as  JANUS(L),  while  the  model 
developed  by  TRAC-WSMR  is  known  as  JANUS(T).  Subsequent  to  their  development, 
both  of  these  models  gained  in  popularity  and  employment  by  a  varied  number  of  users, 
which  led  to  a  wide  proliferation  of  different  versions  of  both  models.  The  JANUS(Army) 
Program  began  in  1989  to  solve  the  standardization  problem  and  to  field  a  single  version, 
JANUS(A),  for  all  Army  users.  Today,  JANUS(A)  is  developed,  maintained,  and 
distributed  by  TRAC-WSMR,  and  is  fielded  throughout  the  world  as  a  tool  for  both  trainers 
and  analysts  in  research  and  development,  testing,  and  combat  development 

B.  DESCRIPTION 

JANUS(A)  is  a  “two-sided,  interactive,  closed,  stochastic,  ground  combat  simulation” 
[JANU  91].  It  is  termed  ‘two-sided’  because  it  allows  the  simulation  of  two  opposing 
forces.  These  two  forces,  the  Blue  force  and  the  Red  force,  are  simultaneously  directed  and 
controlled  on  separate  monitors  by  two  different  sets  of  players.  Each  monitor  displays  only 
the  vehicles  pertaining  to  its  side,  plus  the  opposing  vehicles  which  are  directly  observed 
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by  its  vehicles.  Therefore,  the  model  is  classified  ‘closed’  because  the  friendly  force  player 
does  not  know  the  complete  disposition  of  the  opposing  forces.  The  model  is  ‘interactive’ 
because  each  player  monitors,  directs,  reacts  to,  and  redirects  all  key  actions  of  the 
simulated  units  under  his  control.  Once  a  scenario  is  started,  certain  events  in  the  game, 
such  as  direct  fires  and  artillery  impacts,  are  ‘stochastically’  modelled,  which  means  that 
they  act  according  to  the  laws  of  probability,  and  thus  are  different  for  every  scenario  run. 
The  principal  modeling  focus  in  JANUS(A)  is  on  military  systems  that  participate  in 
maneuver  and  artillery  operations  on  land,  thus  the  term  ‘ground  combat  simulation’. 

C.  HARDWARE 

JANUS(A)  currently  runs  on  any  Digital  Equipment  Corporation  (DEC)  VAX  family 
of  computer  systems  utilizing  the  standard  VMS  operating  system.  A  minimal  hardware 
configuration  (MV3100E  with  12MB  memory  and  four  Tektronix  4225  workstations)  costs 
about  $85,000  [JANU  91].  In  August  1991,  the  Army  directed  that  JANUS(A)  be  fielded 
on  an  “open  system’’.  Since  then,  it  has  been  successfully  demonstrated  on  UNIX  based  X- 
workstations,  and  has  been  benchmarked  as  an  open  system  for  August  1992  [KANA  91]. 

D.  PROGRAM  SUMMARY 

JANUS(A)  is  composed  entirely  of  Army-developed  algorithms  and  data  to  model 
combat  processes.  The  multitude  of  programs  which  belong  to  JANUS(A)  consist  of 
approximately  200,000  lines  of  code  written  entirely  in  VAX-1 1  FORTRAN,  a  structured 
Digital  Equipment  Corporation  (DEC)  extension  of  ANSI  standard  FORTRAN-77  [JANU 
91].  In  addition  to  these  combat  simulation  programs,  JANUS(A)  also  has  eleven  utility 
programs  to  facilitate  the  creation,  running,  and  after-action  analysis  of  a  specific  scenario. 
These  programs  are  outlined  in  Table  1. 
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TABLE  1:  JANUS(A)  PROGRAMS  AND  SUMMARY  DESCRIPTION 


Program 

Description 

TRNFLTR 

Creates  terrain  files  suitable  for  use  by  JANUS(A),  using  any  TRAC- 
WSMR  DMA  terrain  database  as  input 

TED 

Allows  interactive  editing  of  JANUS(A)  terrain  files,  and  the  building  of 
JANUS(A)  display  map  data  files 

SYMBOLS 

Allows  interactive  design  of  graphical  symbols  to  represent  each  type  of 
system  being  modeled 

CSDATA 

Interactively  maintains  the  large  permanent  JANUS(A)  system  perfor¬ 
mance  database 

FORCE 

Allows  interactive  specification  of  the  number  of  each  type  of  system 
comprising  each  force  in  a  particular  scenario 

MERGE 

Allows  a  scenario  to  be  built  from  the  Blue  Forces  of  one  scenario,  and 
the  Red  Forces  of  another  scenario 

VFYSCEN 

Reviews  all  system  and  force  data  for  a  particular  scenario,  and  reports 
errors  or  inconsistencies 

GRAFVFY 

Graphically  displays  each  weapon/system  capability  and  sensor  capabil¬ 
ity  against  opposing  force  systems 

INTTSCEN 

Initializes  an  existing  scenario  for  use  as  a  new  scenario,  or  creates  a  sce¬ 
nario  from  scratch 

POSTP 

Provides  a  history  and  reports  of  nearly  every  event  which  occur  during 
a  JANUS(A)  run 

JAAWS 

Provides  a  quick  graphical  review  of  force  movement,  detections,  and 
attrition  which  occuned  during  a  JANUS  run 

E.  DATA  FILE  MANAGEMENT  AND  CONTENT 

Every  program  included  in  JANUS(A)  is  dependent  on  the  reading  and/or  writing  of 
many  data  files.  Therefore,  fully  integrating  JANUS  (A)  with  the  three-dimensional 
capabilities  of  NPSNET  involves  a  complete  understanding  of  the  content  of  the  various 
files,  and  the  read/write  relationship  between  the  data  files  and  the  different  programs. 
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Below  is  a  description  of  the  organization  and  content  of  the  JANUS  data  files  used  to  set 
up  the  system  (initialization  files),  and  the  JANUS  post-processor  files  used  to  run  the 
scripted  scenarios. 

1.  JANUS(A)  Initialization  Files 

In  the  combat  model  JANUS,  the  initial  state  of  each  scenario  is  recorded  in  the 
files  forceUM.dat,  system#M.dat,  dployM#.dat  and  terain#M.dat.  For  the  first  three  files, 
‘###’  is  a  three  digit  number  fi-om  00 1 -999  which  refers  to  a  specific  scenario.  In  the  terrain 
file,  *###’  is  a  three  digit  number  from  100-999  which  corresponds  to  the  actual  digitized 
terrain  file  used  in  the  model.  These  files  include  information  concerning  the  two- 
dimensional  map,  the  types  and  initial  locations  of  vehicles  and  other  data  pertaining  to  the 
characteristics  of  the  vehicles.  The  JANUS(A)  data  files  are  all  stored  in  VAX  binary 
format  The  following  is  a  brief  description  of  each  of  the  JANUS(A)  file  formats. 

a.  Terrain  Files 

The  file  terainMM.dat,  generated  by  the  programs  ‘TED’  and  ‘TRNFLTR’, 
contains  all  of  the  physical  terrain  information  that  JANUS  requires  to  represent  the  two- 
dimensional  map.  The  terrain  resolution  is  variable,  with  the  standards  being  25,  50,  100, 
and  200  meter  terrain  grids.  The  header  information  in  each  of  the  binary  terrain  files 
consists  of  the  following  specific  information: 

(1)  The  X  and  Y  UTM  coordinates  of  the  lower  left  comer  of  the  map. 

(2)  The  width  and  height  of  the  map  in  kilometers. 

(3)  The  number  of  grid  cells  in  the  X  and  Y  direction. 

(4)  Movement  factors  for  urban  and  vegetated  areas. 

(5)  Vegetation  and  urban  heights  and  probability  of  line  of  sights. 

In  addition,  each  terrain  file  contains  an  array  of  river  nodes  followed  by  an 
array  of  road  nodes.  Each  node  in  the  array  contains  the  X  and  Y  coordinate  of  the  node 
followed  by  a  boolean.  If  the  boolean  is  positive  the  next  node  belongs  to  the  present  node. 
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If  the  boolean  is  zero,  the  next  node  belongs  to  a  new  road  or  river.  And,  if  the  boolean  is 
negative,  it  signifies  the  last  node  in  the  array. 

The  largest  portion  of  the  terrain  file  is  the  data  stored  for  each  terrain  grid 
cell,  which  includes: 

(1)  Elevation  of  the  grid  cell 

(2)  Density  information 

(3)  City  or  tree  present  flag,  and  its  respective  height 

(4)  Trafficability  and  terrain  roughness  information 

(5)  River  present  flag 

(6)  Obstacle  present  flag 

(7)  Flags  representing  smoke,  HE,  chemical,  radiation,  or  fire  present 

h.  System  Files 

JANUS(A)  has  a  very  large  database  which  contains  the  performance  data 
for  every  possible  system,  weapon,  sensor,  mine,  barrier,  and  other  entities  that  can  be 
simulated  by  the  model.  Likewise,  new  combat  systems  or  proposed  systems  can  be  added 
to  the  database.  Because  this  database  is  so  large,  there  are  limits  on  the  number  of  different 
systems  which  can  be  modeled  at  one  time.  Thus,  when  a  new  scenario  is  being  built,  the 
system  types  of  the  units  being  represented  are  copied  from  this  database  to  a  smaller  file 
to  support  the  scenario.  This  smaller  file  is  the  systemttM.dat  file,  and  is  created  by  running 
the  utility  program  ‘FORCE’. 

The  data  comprising  each  system  type  is  enormous,  but  includes  attributes/ 
characteristics  such  as: 

(1)  Names  and  documentation  for  each  system 

(2)  Road  speed 

(3)  List  of  direct  fue  weapons  and  sensors  attached 

(4)  Vulnerability  to  artillery,  direct  fire,  and  mines 

(5)  Probability  of  hit  vs.  range  by  posture,  aspect,  and  motion 

(6)  Probability  of  kill  given  a  hit  vs.  range  by  posture  and  aspect 

[JANU91]. 


8 


c.  Force  Files 

In  addition  to  writing  the  new  scenario  database,  systemM#.dat,  the 
‘FORCE’  program  also  creates  the  data  file  forceitM.dat.  This  file,  which  is  unique  for 
each  different  type  of  scenario  being  modelled,  contains  the  specific  force  structures  of  the 
friendly  and  opposing  units.  In  other  words,  the  units  are  divided  by  side/monitor  and 
further  subdivided  by  task  forces.  Each  side  in  a  JANUS  scenario  can  accommodate  600 
separate  vehicles  for  a  total  of  1200  vehicles  modelled.  The  specific  data  elements  in  the 
force  file  are: 

(1)  System  type,  unit  side,  and  task  force. 

(2)  Number  of  elements  per  individual  system. 

(3)  Number  of  mines,  smoke  grenades,  mine  clearing  equipment,  etc. 

d.  Deployment  Files 

The  data  file  dploy#M.dat  contains  all  of  the  initialization  criteria  for  each 
unit  which  has  been  designated  in  iht  forceMU.dat  file.  The  program  ‘INITSCEN’  creates 
this  deployment  file,  and  must  be  run  each  time  a  scenario  is  changed  from  an  existing 
scenario  or  created  from  scratch.  The  specific  items  contained  in  the  deployment  file  are: 

(1)  Unit  positions  and  movement  routes. 

(2)  Mount  status 

(3)  Planned  direct  fire  and  artillery  missions 

(4)  Barrier  locations. 

2.  JANUS(A)  Post'Processor  Files 

All  significant  events  which  occur  during  a  JANUS(A)  run  are  recorded  in  disk 
files,  called  post-processor  files,  which  can  be  printed  in  a  human  readable  format  to  the 
screen.  The  program  ‘POSTP’  is  available  to  the  JANUS(A)  user  to  produce  these 
historical  reports,  which  are  used  to  analyze  certain  aspects  of  the  battle.  Since  one  of  the 
goals  was  to  produce  a  three-dimensional  playback  capability  of  a  JANUS(A)  scenario, 
these  files  were  significantly  important  to  understand.  There  are  nine  total  post-processor 


files,  but  only  five  of  them,  ppmove###.dat,  ppfirsM#.dat,  ppartyU##.dat,  ppkils^^.dat, 
and  ppmins###.dat,  were  actually  needed  to  create  a  script  capability.  In  all  five  files,  the 
number  ‘###’  refers  to  the  specific  scenario.  Like  the  initialization  files,  these  files  are 
stored  in  VAX  binary  format  The  following  is  a  brief  description  of  each: 


TABLE  2:  JANUS(A)  POST-PROCESSOR  FILES  AND  DESCRIPTION 


PP  File 

Description 

PPMOVE 

Sequential  list  by  game  time,  of  the  location  of  every  unit,  by  vehicle 
number  and  side. 

PPFIRS 

Sequential  list,  by  game  time,  of  the  location  and  speed  of  the  hrer  and 
the  target 

PPARTY 

Sequential  list  by  game  time,  of  the  location  of  the  firer,  type  of  volley, 
number  of  rounds  fired,  and  location  of  impact. 

PPKILS 

Sequential  list  by  game  time,  of  the  location  of  the  firer  and  the  victim 
and  the  kill  type. 

PPMINS 

A  record  of  all  minefields,  fascams,  and  gems  activated  during  the  run. 
Includes  the  location,  type,  size,  number  of  mines,  etc. 
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ni.  TWO-DIMENSIONAL  TERRAIN  AND  SCRIPTING 

The  first  step  in  developing  a  realistic  three-dimensional  virtual  world  and  a 
representative  scripting  capability  for  previously  run  scenarios  was  to  build  a  two- 
dimensional  prototype.  This  system,  run  entirely  on  an  SGI/IRIS,  was  extremely  effective 
in  testing  the  validity  of  the  converted  terrain  model  and  the  accuracy  of  the  conversion 
udlides  developed  to  transform  the  JANUS(A)  initialization  and  post-processor  files  into  a 
format  usable  by  NPSNET.  The  different  hardware  systems  caused  a  significant 
compatibility  problem.  Appendix  A  discusses  the  methods  used  to  convert  VAX  formatted 
files  to  a  format  compatible  with  the  Silicon  Graphics  Computers.  This  chapter  describes 
the  file  management  system  developed  for  the  converted  files.  It  also  discusses  the  two- 
dimensional  replay  model  which  was  developed. 

A.  SGI  FORMATTED  JANUS(A)  FILES 

This  section  briefly  describes  the  format  and  content  of  the  converted  JANUS(A) 
inidalization  and  post-processor  files.  For  simplicity  in  reading  and  validadng  the  data,  all 
of  the  VAX  to  SGI  converted  data  are  stored  as  text  files. 

1.  Initialization  Files 

As  stated  in  Chapter  D,  the  initial  state  of  each  scenario  is  recorded  in  the  files 
forceMit.dat,  systemic. dot,  dployffMxiat  and  terainMif.dat.  These  files  include 
information  concerning  the  two-dimensional  map,  the  types  and  initial  locations  of 
vehicles,  and  other  data  pertaining  to  the  characteristics  of  the  vehicles. 

a.  Terrain  Files 

The  conversion  program  for  the  terrain  files  is  called  readtrrn.c.  It  takes,  as 
input,  the  three  digit  number  *###’  signifying  the  digitized  map  used  in  the  model.  The 
corresponding  JANUS(A)  terrain  file,  rerain###.dar,  is  first  decoded  and  then  written  into 
three  different  text  files  corresponding  to  the  grid  cell  data,  the  river  array  data,  and  the  road 
array  data.  The  grid  cell  data  is  stored  in  the  file  and  begins  with  a  header 


11 


containing  the  lower  left  X  and  Y  coordinates,  the  number  of  grid  cells,  and  the  map 
resolution.  The  remainder  of  the  grid  cell  data  is  formatted  as  shown  in  the  table  below. 


TABLE  3:  CONVERTED  GRID  CELL  DATA  FILE  FORMAT 


XCell 

YCell 

Elevation 

Density 

CityA'ree 

... 

HE 

0 

0 

324.0 

5 

0 

... 

0 

1 

0 

332.0 

7 

1 

... 

0 

... 

120 

120 

333.0 

3 

0 

... 

0 

The  river  array  and  road  array  data  are  contained  in  ###.rjv  and  UM.road 
respectively.  They  each  contain  a  line  entry  for  the  X  coordinate  of  a  node,  followed  by  the 
Y  coordinate,  and  lastly  a  boolean  representing  (1)  the  continuation  of  a  river/road,  (2)  the 
end  of  a  river/road,  or  (3)  the  end  of  all  rivers/roads. 

b.  System  Files 

The  conversion  program  for  the  system  files  is  called  readsy^les.c.  It  takes, 
as  input,  the  three  digit  number  *###’  signifying  the  scenario  number  being  used  in  the 
model.  As  mentioned  in  Chapter  II,  this  system  file  is  enormous  and  contains  almost  every 
conceivable  bit  of  performance  data  available  for  any  weapon  system.  Since  the  system 
only  simulates  what  JANUS(A)  has  already  modeled  in  a  scenario,  most  of  the  information 
in  this  system  file  is  not  needed.  Thus,  after  decoding  syst€mitiftt.dat,  information  is  written 
to  only  three  different  text  files.  The  first,  sysjbrce.dat,  contains  all  of  the  information 
needed  to  match  the  proper  icon  symbol  to  the  appropriate  system.  The  next,  name. dot,  is 
a  table  matching  the  different  system  numbers  to  the  actual  assigned  JANUS  system  name. 
And  the  last,  cloud.dat,  contains  the  cloud  ceiling,  wind  direction  and  speed,  and  the  cloud 
coefficients. 
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c.  Force  Files 

Once  the  system  file  has  been  converted,  the  conversion  program  for  the 
force  file,  reac^orcefile.c  can  be  run.  Like  the  others,  it  accepts  the  three  digit  number  *###’ 
signifying  the  scenario  number  being  used  in  the  model.  For  the  same  reasons  as  the  system 
file,  much  of  the  data  written  in  forceUUU.dat  is  not  needed  for  the  simulation.  After 
decoding  the  force  file,  information  is  written  to  three  different  text  files.  The  first, 
sysnames.dca,  matches  a  unique  vehicle  to  its  specific  system  number  and  text  name.  The 
second,  force. data,  matches  a  unique  vehicle  to  its  side,  vehicle  number,  vehicle  type,  task 
force,  and  number  of  subordinate  elements.  The  last  file,  icontable.dat,  matches  a  unique 
vehicle  to  its  appropriate  two-dimensional  JANUS(A)  icon  symbol. 

d.  Deployment  Files 

The  conversion  program  for  the  deployment  file  is  readdeploy.c.  It  also 
accepts  the  three  digit  number  '###’  signifying  the  scenario  number  being  used  in  the 
model.  After  decoding  the  deployment  file,  dploytfM.dat,  one  text  file  is  written.  This  file, 
initunit.dat,  simply  contains  the  initial  positions  and  orientations  for  every  vehicle  in  the 
scenario. 

2.  SGI  Formatted  Post-processor  Files 

The  conversion  program  for  the  post-processor  files  is  readppfUes.c.  It  accepts 
the  three  digit  number,  ‘###’,  matching  the  scenario  which  has  previously  been  run  and 
saved.  It  sequentially  decodes  all  five  post-processor  files,  then  writes  all  of  the  data  from 
each  into  their  respective  text  files.  For  example,  the  JANUS(A)  post-processor  file, 
ppmoveMlt.dat,  would  be  transformed  from  VAX  to  SGI  format,  then  written  into  the  text 
file  ppmove.dat. 

B.  REPLAY 

The  next  step,  after  ( 1 )  converting  and  formatting  the  JANUS(A)  data  files  from  VAX 
to  DEEE  and  (2)  arranging  them  in  the  new  file  management  system,  was  to  test  the  display 
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of  the  two-dimensional  terrain,  vegetation,  and  cultural  features  on  the  prototype  system. 
In  addition  to  the  map  display,  the  validity  of  the  initialization  and  post-processor  files  were 
tested  by  creating  a  two-dimensional  scripting  capability.  This  section  discusses  this  two- 
dimensional  terrain  and  scripting  program,  ‘REPLAY’. 


1.  Two-Dimensional  Map  Generation 

All  of  the  information  needed  for  the  creation  of  the  two-dimensional  map, 
except  for  the  roads  and  rivers,  is  found  in  the  converted  file  Mi^.ele  (see  table  3).  The  most 
important  part  of  this  file  is  the  elevation  data  that  is  provided  for  each  grid  cell.  As 
mentioned  in  Chapter  II ,  there  are  several  different  resolutions  available  for  any  particular 
piece  of  terrain.  The  elevations  given  for  a  specific  grid  cell  correspond  diiecdy  to  the 
resolution  of  the  map.  For  example,  if  a  map  had  a  resolution  of  1(X)  meters,  each  elevation 
would  correspond  to  a  1(X)  x  1(X)  meter  section  of  ground.  To  accurately  portray  this  terrain, 
the  elevations  are  represented  by  coloring  each  one  a  brighter  shade  of  grey  from  the 
minimum  to  the  maximum  elevation.  Since  there  are  255  different  available  shades  of  grey, 
the  proper  grey-scale  is  calculated  by  using  the  ratio  shown  in  Equation  3.1  (PRAT  90]. 


COLOR  =  (ELEVATION min 


ELEVATION  -  ELEVATION  min 
^  ^  ELEVATION  max  ~  ELEVATION  min  ^ 


(Eq3.1) 


Using  this  equation  resulted  in  an  esthetic  view  and  accurate  representation  of  the 
two-dimensional  map.  An  example  of  a  100  meter  resolution,  12x12  kilometer  section  of 
terrain  being  rendered  by  the  program,  ‘REPLAY’,  is  shown  in  Figure  1. 
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Figure  1:  Fulda  Gap  Being  Rendered  by  Grey-Scaling  Algorithm. 

As  discussed  above,  the  itM.ele  file  contains  much  more  than  just  elevations.  All 
of  these  pieces  of  information  are  displayed  to  the  screen  in  a  similar  manner  as  the  grey¬ 
scale  map.  The  cities  are  displayed  in  shades  of  dark  grey,  and  the  vegetation  is  displayed 
in  shades  of  green,  each  COTiesponding  to  their  appropriate  density  values.  Yet,  unlike  the 
grey-scale  map,  which  is  permanently  displayed  on  the  screen,  the  remainder  of  the  terrain 
and  cultural  features  is  displayed  by  a  pop-up  menu.  These  features  are  then  be  rendered  or 
hidden  as  needed. 

The  road  and  river  data,  contained  in  their  own  separate  files,  is  simply  a 
collection  of  conrtected  nodes.  These  features  are  also  rendered  through  a  pop-up  menu, 
which  simply  ctmnects  the  nodes  with  black  lines  for  roads  and  blue  lines  for  rivers.  An 
example  of  cities,  vegetation,  roads,  and  rivers  is  shown  in  Figure  2.  It  is  being  displayed 
on  the  same  grey-scaled  map  featured  in  Figure  1. 
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Figure  2:  Fulda  Gap  with  Optional  Terrain  Features. 

2.  Two-Dimensional  Scripting  Capability 

With  the  terrain  file  verified,  the  next  step  was  to  produce  a  representative  two- 
dimensional  script  of  a  scenario  which  had  been  previously  run  on  the  traditional 
JANUS(A)  model.  The  appropriate  vehicles  are  successfully  matched  to  their  side  (red  or 
blue)  and  to  their  particular  icon  symbol  by  using  the  converted  force  and  system  Hies. 
Then,  the  converted  deployment  file  is  used  to  properly  render  each  vehicle,  according  to 
its  two-dimensi<mal  icon,  at  the  appropriate  initial  position.  This  validated  the  conversion 
and  format  utilities  fen*  the  initialization  files. 

Next,  the  playback  capability  was  created  by  using  the  data  contained  in  the  five 
converted  post-processor  files.  Each  file’s  information  was  loaded  into  separate  arrays 
based  on  the  clock  time,  in  seconds,  that  the  event  occurred.  Like  the  terrain  features,  a  pop- 
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up  menu  is  used  to  start  the  ‘replay’  action.  When  the  playback  option  is  activated,  the 
program  sets  the  elapsed  time  to  zero.  Then,  as  the  elapsed  time  progresses,  each  of  the 
array’s  clock  times  are  checked  against  it  If  an  event  matches  the  system  clock,  it  is 
activated. 

Minetields  are  drawn  as  rectangles,  with  the  proper  length,  width,  and 
orientation.  Movement  events  are  shown  by  simply  moving  the  two-dimensional  icon  to  its 
next  position.  Direct  fire  events  are  drawn  with  straight  lines,  with  blue  representing 
friendly  fire  and  red  representing  enemy  fire.  Indirect  fire  events  are  depicted  as  circles. 
The  edges  of  the  circles  are  colored  according  to  the  side  (red  or  blue),  and  the  interior  of 
the  circle  is  painted  black  for  high  explosive  or  white  for  smoke.  Smoke  rounds  remain  on 
the  map  undl  their  determined  dissipation  time.  Destroyed  vehicles  are  changed  to  a  green 
color,  and  remain  on  the  map  at  that  position.  An  example  of  the  playback  program  is 
shown  in  Figure  3. 
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Figure  3;  Fulda  Gap  with  Roads  and  Scripted  Battle. 

The  ‘REPLAY’  program  proves  that  the  conversion  programs  and  display 
algorithms  for  the  post-processor  riles  are  identical  in  every  detail  to  the  original  scenario 
run  on  the  actual  JANUS(A)  model.  This  conrirmed,  the  next  step  was  integrating 
JANUS(A)  with  the  three-dimensional  model  NPSNET,  as  discussed  in  the  next  chapter. 


18 


IV.  NPSNET:  INTEGRATION 


This  chapter  provides  an  overview  of  NPSNET  and  the  methods  used  to  integrate 
NPSNET  with  the  JANUS(A)  combat  model.  Topics  discussed  are  the  functions,  programs 
and  utilities  required  to  create  three-dimensional  terrain  skin  for  the  JANUS(A)  model 
within  the  NPSNET  system.  The  procedures  necessary  to  generate  the  triangular-mesh  and 
the  polygonized  three-dimensional  terrain,  together  with  the  methods  used  to  create  cities, 
trees  and  tree  canopies  are  discussed.  Also  an  algorithm  to  insure  that  trees  and  buildings 
are  not  drawn  on  rivers  and  roads  is  presented. 

A.  BACKGROUND 

The  Naval  Postgraduate  School’s  Computer  Science  Department  created  a  system  to 
render  three-dimensional,  real  time  simulations  of  military  vehicles  and  terrain  databases 
known  as  NPS  Networked  Vehicle  Simulator  (NPSNET).  Specific  attributes  of  the  system 
include  creating  a  three-dimensional,  real  time,  virtual  world  at  a  cost  of  well  under 
$100,000  [ZYDA  92].  Furthermore,  it  possesses  the  ability  for  quick  adaptation  with 
applications  involving  other  modeling  systems.  In  particular  this  chapter  refers  to  the 
ongoing  development  of  applications  and  interfaces  for  NPSNET  with  the  JANUS(A) 
combat  modeling  system. 

B.  HARDWARE 

NPSNET  currently  runs  on  a  Silicon  Graphics  Incorporated  (SGI),  IRIS/4D  family  of 
computer  systems  utilizing  the  IRIX  (UNIX  based)  operating  system  [SGI  91].  The  entry 
level  hardware  for  this  model  is  the  SGI  Indigo-Elan  with  16MB  of  memory  and  100MB 
of  available  disk  space.  The  cost  for  the  minimal  system  is  approximately  $27,000. 

C.  DESCRIPTION 

NPSNET  utilizes  two  techniques  to  render  terrain,  using  either  triangular-mesh  or 
discrete  polygons  as  basic  building  blocks.  The  triangular-mesh  terrain  provides  an 
efficient  and  simple  terrain  skin  for  the  virtual  world,  but  currently  does  not  allow  roads 
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and  rivers  to  be  drawn  without  significant  tearing.  In  order  to  realistically  provide  the 
ability  to  render  roads  and  rivers,  NPSNET  instead  utilizes  the  discrete  polygon 
(polygonized)  terrain  model  [PRAT  92].  All  objects  (such  as  trees,  vehicles  and  buildings) 
are  rendered  using  a  system  known  as  NPSOFF  [ZYDA  91a].  These  stationary  objects  and 
polygonized  tenain  data  are  stored  in  files  indexed  by  coordinates  which  match  their 
corresponding  terrain  node  (Terrain  nodes  are  discussed  in  Section  IV.G.).  Moving  objects 
are  stored  in  an  array  assigned  to  each  terrain  node.  Their  positions  are  updated  each  time 
the  graphics  loop  is  executed  [MACK  91]. 

NPSNET  currently  provides  three  modes  of  combat  modeling.  First,  the  model  can 
be  played  in  a  networked,  multi-user  mode.  In  this  mode,  one  or  more  players  can  chose 
and  maneuver  any  vehicle  in  the  three-dimensional  virtual  world.  They  can  decide  to  fight 
with  or  against  one  another  over  the  network.  Additionally,  a  player  can  choose  to  fight  a 
set  of  semi-automated  forces.  Players  can  view  the  world  from  the  perspective  of  the 
vehicle  commander  or  from  an  observer  controller  vehicle.  The  second  modeling  mode 
NPSNET  uses  is  a  script.  With  this  method,  the  user  can  prepare  scripted  scenarios  of 
combat  operations  and  view  the  results  in  three-dimensions.  The  last  mode  includes 
receiving  inputs  over  an  Ethernet  network  from  other  three-dimensional  combat  models 
such  as  SIMNET.  In  this  mode,  NPSNET  can  fully  interact  with  the  other  combat  model. 

D.  NPSNET  VEHICLE  MOVEMENT  AND  SIMULATION 

1.  Vehicle  Models 

NPSNET  provides  an  assortment  of  U.S.  and  foreign  weapons  system  models. 
Currently,  vehicle  models  range  from  U.S.  MlAl  tanks  and  A-10  jet  aircraft  to  Soviet 
made  T72  tanks  and  BMPs.  All  of  these  vehicles  are  formatted  and  rendered  using  the 
NPSOFF  system  [ZYDA  91a]. 

2.  Vehicle  Data  Structure 

All  information  concerning  the  disposition  of  vehicles  is  stored  in  a  data 
structure  named  vehpostype.  This  structure  contains  the  information  listed  in  Figure  4. 
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int  vehnum; 
int  vehtype; 
int  control; 
int  undiiven_control: 
int  gunfire; 
int  alive; 
float  pos[3]; 
float  direction, 
viewdirection, 
elev, 
gunelev, 
speed, 
roll, 
pitch; 

intjan  type; 
int  b^avior; 
int  round; 
int  deadframes; 
tong  deadtime; 
int  coll  interval- 
float  ey^3], 
lookatpt[3], 
lookfromptt3]; 
float  gas; 


TThe  vehicle  identification  number  in  NPSNET  */ 

TType  of  vehicle  model,  an  index  into  vehtypearray  */ 
r  Who  is  controlling  it(i.e.  script,  network,  etc.*/ 
r  Who  controls  it  when  it's  not  the  driven  vehicle?  */ 
r  Did  it  shoot  in  the  last  frame  */ 
r  Vehicle  is  alive  or  dead  */ 
r  Vehicle  position  in  space  (i.e.  3D  grid  coordinates)*/ 

/*  X-Z  plane  orientation  of  veh  in  radians  */ 
r  X-Z  plane  orientation  of  the  drivers  view  in  radians  */ 
r  Vehicles  meters  above  ground  (aircraft  and  observer)  */ 
r  Quadrant  elevation  of  tube  in  degrees*/ 
r  Meters  per  second  */ 
r  Degrees*/ 
r  Degrees*/ 

/*  Specifies  janus  symbol  in  2d  map  */ 
r  What  type  of  behavior  it  is  exhibiting*/ 
r  Number  rounds  of  ammunition  vehicle  has  left*/ 

/*  Number  of  frames  has  it  been  dead*/ 

/*  Time  vehicle  has  been  dead*/ 

/*  Minimum  safe  passing  distance*/ 

/*  Location  of  the  viewers  eye  in  world  coordinates.*/ 

/*  Location  of  the  point  the  viewer  is  looking  at.*/ 

/*  Where  viewer  is  looking  when  not  in  vehicle*/ 

/*  Fuel  remaining  in  vehicle*/ 


Figure  4:  Vehicle  Information  Data  Structure 
Every  vehicle  present  in  a  simulation  is  described  with  one  of  these  vehpostype 
data  structures,  which  is  stored  in  an  array  named  ve/iflrrr^[MAXNUMVEHICLES]. 
MAXNUMVEHICLES  is  a  variable  indicating  the  maximum  number  of  vehicles  that  the 
simulation  will  allow  —  currently  500. 

The  following  discussion  refers  to  the  variables  listed  in  Figure  4.  The  index  for 
a  particular  vehicle  in  veharray  is  identical  to  vehnum  for  the  vehicle.  At  initialization,  each 
vehicle  that  is  input  into  the  simulation  is  assigned  a  sequential  vehnum  begiiming  with  the 
number  one.  The  observer  controller  vehicle  has  the  number  zero  assigned  as  its  vehnum. 
It  is  important  to  note  that  NPSNET  uses  a  one  dimensional  anay  to  store  vehicle 
information.  This  requires  only  a  single  index  to  identify  a  unique  vehicle  in  a  simulation. 
JANUS  (A),  on  the  other  hand,  stores  all  of  its  vehicle  information  in  a  two-dimensional 
array,  thus  requiring  two  indices  to  identify  a  vehicle.  A  cross  indexing  routine,  to  allow 
the  proper  identirication  of  a  vehicle  between  the  two  systems,  is  discussed  in  Chapter  V. 
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Vehtype  is  a  variable  that  indicates  which  of  the  NPSOFF  vehicle  models  is 
rendered  for  the  particular  vehicle.  The  control  variable  indicates  whether  or  not  the 
operator  of  the  simulation  is  currently  driving,  thus  controlling,  the  vehicle.  If  a  vehicle  is 
not  being  controlled  by  the  operator,  it  is  assigned  the  variable,  undrivencontrol.  The  modes 
offered  for  an  undriven  vehicle  include  receiving  commands  from  a  script,  receiving 
commands  from  the  network,  receiving  commands  through  the  semi-automated  force 
system,  or  simply  continuing  at  the  same  speed  and  direction  that  it  currently  has  until  the 
operator  of  the  simulation  changes  it. 

The  variables  that  are  of  particular  importance  to  the  current  disposition  of  a 
vehicle  in  the  three-dimensional  world  aiepos[3],  viewdirection,  direction,  elev  and  speed. 
The  variable,  pos[3],  is  an  array  containing  the  grid  coordinates  for  a  vehicle.  Viewdirection 
stores  the  angle  of  the  turret  (or  angle  of  operators  view)  based  on  a  coordinate  system  local 
to  the  vehicle  itself.  (Note:  The  X  axis  is  considered  the  base  axis  from  which  all 
measurements  begin  and  the  positive  direction  of  measure  is  clockwise.)  The  variable, 
direction,  is  the  angle  of  the  base  of  a  vehicle  with  respect  to  the  NPSNET  terrain 
coordinate  system.  The  elev  variable  indicates  the  number  of  meters  a  vehicle  is  above  the 
terrain.  Only  aircraft  and  the  observer  controller  vehicle  can  have  an  elev  value  greater  than 
zero.  The  speed  variable  indicates  the  cunent  speed  of  a  vehicle,  and  is  measured  in  meters 
per  second  in  the  NPSNET  simulation. 

The  other  variables  that  are  listed  in  the  vehpostype  are  important  to  the 
functioning  of  the  NPSNET  simulation  but  are  not  relevant  to  the  translation  of  JANUS(A) 
data.  Therefore,  they  will  not  be  discussed. 

3.  Vehicle  Activity  in  NPSNET 

Every  time  the  graphics  loop  is  executed,  each  element  in  the  veharray  is 
updated.  Based  on  the  current  speed  and  direction  recorded  for  a  vehicle,  the  new  position 
is  calculated  and  stored  in  the  pos[3]  variable.  The  vehicle  is  then  rendered  at  this  new 
location,  with  the  orientation  of  the  vehicle  and  turret  prescribed  by  the  direction  and 
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viewdirection  variables.  These  orientations  can  be  changed  by  inputs  from  the  user  at  the  keyboard 
or  with  the  space  ball  [MACK  91]. 

Other  activities  such  as  gunfire,  or  the  destruction  of  a  vehicle,  are  stored  in  the  veharray 
for  a  vehicle.  When  the  graphics  loop  updates  the  vehicle,  it  will  render  the  appropriate  response  as 
indicated  by  the  variables  in  the  array.  Activities  of  a  very  short  duration,  such  as  gunfire,  are  reset 
to  no  gurtfire  after  the  vehicle  array  is  updated. 

E.  GENERATION  OF  NPSNET  ELEVATION  FILES 


1.  JANUS(A):  Coordinate  System. 

NPSNET  uses  the  JANUS(A)  terrain  database  to  construct  the  three-dimensional  terrain. 
The  JANUS(A)  terrain  database  is  merely  a  collection  of  grid  coordinates  with  an  elevation  assigned 
to  each  coordinate.  In  order  to  store  these  elevations  in  a  sequential  file  format,  JANUS(A)  divided 
the  terrain  into  a  grid.  The  spacing  between  the  horizontal  and  vertical  lines  is  known  as  the 
resolution  value  and  is  labeled  “GAP”  throughout  the  code.  Each  intersection  is  labeled  by  the 
cartesian  coordinates  of  the  horizontal  and  vertical  line  that  make  up  the  intersection.  The  elevation, 
tree  or  city  present  flag,  and  its  respective  height  factor  are  recorded  for  each  of  these  intersections. 
These  grid  intersections  will  be  referred  to  as  “checkpoints”  in  the  remainder  of  this  document 
JANUS(A)  references  the  cartesian  coordinates  for  each  checkpoint  using  its  UTM  coordinate  as 
indicated  in  Figure  5.  These  UTM  coordinates  are  translated  to  a  local  coordinate  system  where  the 
lower- left  hand  comer  of  the  map  has  the  coordinates  (0, 0)  using  Equation  4.1  and  Equation  4.2 
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Figure  5:  Description  of  JANUS  Map  Resolution 
2.  NPSNET:  Coordinate  System 

Unlike  JANUS(A),  NPSNET  utilizes  a  local  coordinate  system  where  the  upper- 
left  hand  comer  of  the  map  is  labeled  (0,  0).  Therefore,  to  allow  NPSNET  the  ability  to 
accurately  reference  the  JANUS  terrain  database,  each  set  of  JANUS(A)  coordinates  are 
translated  to  reflect  the  NPSNET  system.  Since  the  x  coordinate  in  the  NPSNET  coordinate 
system  is  the  same  as  the  x  coordinate  for  the  JANUS(A)  local  coordinate  system,  no 
further  translation  of  the  x  coordinate  is  required.  But  because  they  coordinates  for  the  two 
systems  are  not  the  same  each  local  JANUS(A)  y  coordinate  is  translated  to  match  the 
NPSNET  coordinate  system.  This  translation  is  accomplished  by  subtracting  each  local 
JANUS(A)  y  coordinate  from  the  total  height  of  the  map  as  written  in  Equation  4.3.  (The 
z  coordinate  in  three-dimensions  is  equivalent  to  the  two-dimensional  y  coordinate.  The 
remainder  of  the  document  will  use  the  z  coordinate  when  referencing  the  two-dimensional 
y  coordinate.) 

^NPSNETj  ~  (Eq4.3) 

As  explained  in  Chapter  III,  these  translated  coordinates,  along  with  the 
elevations,  road  present,  river  present,  city  or  tree  present,  nticro-terrain  roughness,  and 
trafficability  corridors  for  each  checkpoint  are  stored  in  the  file  “#^.e/e”. 
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Figure  6:  NFS  NET:  Coordinate  System 

F.  GENERATING  MESH  TERRAIN 

1.  Creating  the  Binary  Elevation  file. 

The  binary  elevation  file  is  key  to  the  creation  of  the  three-dimensional  mesh 
terrain,  and  the  determination  of  the  locations  of  all  objects  within  the  three-dimensional 
world.  The  program  "genbinaryelev.c"  extracts  the  elevation  data  from  the  file,  U##.ele. 
Then  these  elevations  are  then  rewritten  in  column-major  order  (using  the  NPSNET 
cartesian  coordinates  as  indices)  to  the  binary  file,  elev.bin.dat. 

2.  Creating  Mesh  Terrain 

Mesh  terrain  is  created  using  the  built  in  “IRIS”  function  for  drawing  a  triangular 
mesh,  commonly  referred  to  as  “t-mesh”.  Each  checkpoint  is  treated  as  one  of  the  three 
points  of  a  triangle.  The  t-mesh  terrain  skin  is  built  by  moving  from  the  left  to  the  right  of 
the  map,  then  from  the  bottom  to  the  top  of  the  map.  Figure  7  depicts  the  path  of  points  used 
in  the  t-mesh  function. 
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Figure  7:  Tri-Mesh  Terrain  Traversal  Pattern 
When  the  right  side  of  the  map  is  reached,  the  mesh  terrain  algorithm  moves  the 
pointer  back  to  the  left  edge  and  begins  the  next  row.  As  stated  earlier,  the  mesh  terrain  is 
more  efficient  and  simpler  to  implement  for  the  terrain  model,  but  roads  and  rivers  cannot 
be  displayed  on  this  terrain  without  significant  tearing. 

G.  GENERATION  OF  POLYGONIZED  TERRAIN  SKIN 

The  best  three-dimensional  terrain  image  is  rendered  using  a  terrain  skin  comprised  of 
discrete,  triangular  polygons.  Because  each  polygon  is  a  discrete  element,  each  one  can  be 
manipulated  -  or  any  object  on  it  —  with  great  precision. 

1.  Structure  of  Polygonized  Terrain 

a.  Description  of  Grid  Node 

A  grid  node  is  the  basic  building  block  for  polygonized  terrain  (see  Figure 
8).  Each  node  is  made  up  of  two  triangles,  an  upper  and  a  lower.  (From  the  figure  it  appears 
that  the  positions  of  the  two  triangles  are  reversed,  however,  because  measurements  are 
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taken  from  the  upper-left  hand  comer  of  the  mai ,  the  upper  triangle  is  the  triangle  farthest 
from  the  origin.) 


Figure  8:  Basic  Terrain  Node 

The  numbering  for  each  grid  node  uses  the  upper-left  hand  comer  of  the 
square  as  the  local  origin,  with  each  comer  of  the  node  representing  a  checkpoint  from  the 
database.  Each  side  of  the  basic  grid  node  is  equal  to  the  resolution  value  (GAP). 

b.  Polygonized  Terrain  Resolution 

The  polygonized  terrain  is  displayed  with  four  degrees  of  resolution.  The 
triangular  polygons  that  make  up  the  highest  level  of  resolution  have  side  lengths  equal  to 
the  resolution  value  (GAP)  of  the  database.  The  lower  resolution  polygons  are  larger  (twice 
the  size  of  the  next  higher  resolution),  thus,  they  are  a  less  accurate  depiction  of  the  terrain. 
High  resolution  terrain  is  rendered  as  the  set  of  polygons  that  are  closest  to  the  viewers  look 
at  point,  while  lower  resolution  polygons  are  rendered  for  terrain  that  is  at  increasingly 
greater  distances  from  the  viewers  coordinates.  Currently,  high  resolution  polygons  are 
used  for  terrain  that  is  within  a  1000  meter  bounding  box  of  the  viewers  x  and  z  coordinates. 
Successively  lower  levels  of  resolution  are  used  for  polygons  that  are  at  distances  greater 
than  25(X),  4500  and  6000  meter,  as  measured  from  a  bounding  box  that  surrounds  the 
viewer’s  position[MACK  91].  By  using  low  resolution  polygons  for  distant  terrain,  the 
number  of  polygons  rendered  is  significantly  reduced  without  sacrificing  detail.  This 
reduction  increases  the  frame  rate  and  efficiency  of  the  machine. 
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c.  Description  of  a  Terrain  Quadtree 


Because  each  grid  cell  of  the  terrain  is  represented  by  four  different 
resolution  sets  of  polygons,  a  special  data  structure  was  implemented  to  store  the  data.  This 
structure  is  called  a  quadtree  -  a  type  of  hierarchical  data  structure  based  on  recursive 
subdivisions.  The  general  idea  behind  quadtrees  is  that  each  level  of  the  tree  provides  a 
more  detailed  description  of  an  image  or  data.  Nodes  are  either  internal  (with  four  children) 
or  are  terminal  (with  no  children).  They  can  be  used  to  reduce  storage  space  for  data  or  to 
provide  multiple  resolution  versions  of  data  [MACK  91]. 

In  order  to  get  the  transposed  JANUS  (A)  database  into  the  NPSNET 
quadtree  format,  the  terrain  is  divided  into  blocks  of  cells.  Each  block  is  eight  grid  cells 
long  and  wide,  and  is  marked  as  item  “D”  in  Figure  9.  This  “D  node”  is  the  basic  unit  of 
storage  for  the  terrain  base,  and  is  further  subdivided  into  four  nodes  or  children.  These 
children  are  labeled  as  the  set  of  “C”  nodes.  Each  “C”  node,  too,  is  subdivided  into  four 
nodes  labeled  as  the  set  “B”.  And  finally  each  “B”  node  is  divided  into  four  “A”  nodes.  The 
length  of  the  side  of  the  block  is  eight  times  that  of  the  GAP  for  the  terrain.  The  comers  of 
the  upper  and  lower  triangles  are  locally  represented  as  (x,  z),  (x+8,  z),  (x,  z+8)  and  (x+8, 
z+8).  The  resolution  levels  for  the  quadnodes  are  labeled  as  follows: 

•  HIGH  1  Side  Length  =  GAP 

•  HIGH-MEDIUM  2  Side  Length  =  GAP  *  2 

•  LOW-MEDIUM  3  Side  Ungth  =  GAP  *  4 

•  LOW  4  Side  Length  =  GAP  *  8 
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Figure  9:  Quadtree:  Terrain  Illustration 
These  sets  of  nodes  are  stored  in  the  quadtree  structure,  with  each  node  or 
cell  representing  a  node  in  the  tree,  and  the  four  nodes  that  make  up  the  subdivision  of  a 
larger  node  are  children  of  the  divided  node  (see  Figure  10).  The  quadtree  data  structure 
produces  a  shallow  tree  that  can  quickly  be  searched  to  find  the  terrain  cells  required. 


Figure  10:  Quadtree:  Data  Structure  Illustration 
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2.  Generating  Terrain  Polygons 


The  program  "genblockcov.c"  divides  the  map  into  sets  of  quadtrees.  In  order  to 
have  a  whole  number  of  quadtrees  in  the  database,  the  width  of  the  entire  map 
(XMAPSIZE)  and  the  height  of  the  map  (ZMAPSIZE)  must  be  a  multiple  of  the  product  of 
the  GAP  value  and  the  integer  8.  (See  Eq  4.3) 

I  KT  u  MAPSIZE 

Whole  Number  =  ^  (Eq4.4) 

If  the  map  size,  in  either  the  x  or  y  direction,  does  not  provide  a  whole  number, 
as  indicated  in  Equation  4.4,  then  additional  checkpoints  need  to  be  added  to  the  database 
until  Equation  4.4  is  satisfied.  The  calculation  to  check  for  the  appropriate  number  of 
checkpoints  is  conducted  in  the  program  ''readtrrn.c".  If  mere  checkpoints  are  required, 
then  the  checkpoints  are  all  given  the  elevation  of  the  lower-left  comer  of  the  map.  The 
following  algorithm  describes  the  additions  of  the  checkpoints  to  the  database. 


/*  Determine  if  extra  checkpoints  are  needed  to  make  */ 
/*  the  number  of  quadnodes  a  whole  number.  */ 
z_nuni_extra_nodes  =  (ZMAPSIZE  /  GAP)  mod  8 
x_num_extra_nodes  =  (XMAPSIZE  /  GAP)  mod  8 
if  (x_num_extra_nodes  !=  0.0)  then 
old_x_num_grids  =  x_num_of_grids 
/*  Add  the  new  x  direction  checkpoints  */ 
x_num_of_grids  =  x_num_of_grids  +x_num_extra_nodes 

if  ( z_num_extra_nodes  !=  0.0)  then 
old_z_num_grids  =  z_num_of_grids 
/*  Add  the  new  z  direction  checkpoints  */ 
z_num_of_grids  =  z_num_of_grids  +z_niim_extra_nodes 

/*  Fill  the  elevation  value  of  the  new  checkpoints  */ 
for  i  =  old_x_num_grids  to  x_num_of_grids  loop 

for  j  =  old_z_num_grids  to  z_num_of_gr ids  loop 
grid(i,  j). elevation  =  grid(0,  0) .elevation 
end  loop 
end  loop 


Figure  1 1 :  Algorithm  to  Adjust  Map  Size  According  to  Quadnode  Requirements 
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Each  set  of  data  for  a  quadtree  is  stored  in  a  unique  file  labeled 
coverXXZZbin.dat,  where  XX  and ZZ  reference  the  x  and  z  indices  for  the  quadtree.  In  order 
to  optimize  the  search  routines  within  a  quadtree,  each  quadtree  structure  is  represented  as 
a  heap  in  the  code.  A  heap  sort  is  used  to  find  the  correct  resolution  level  within  the  file 
[MACK  91]. 

Each  node  of  the  quadtree  is  represented  in  the  cover  file  as  two  sets  of  three 
points  each,  with  each  triple  of  points  representing  the  upper  and  lower  triangle  of  the  node. 
With  each  point  set,  the  quadtree  indices,  number  of  points  in  the  set,  the  color  for  the 
triangle,  an  index  indicating  if  the  triangle  is  an  upper  or  lower  triangle,  the  normals  for  the 
triangle  and  the  resolution  level  of  the  polygon  are  recorded.  Figure  12  illustrates  the 
storage  pattern  for  a  single  node. 


normals 


0  119  3  12  1  u  ◄ - 
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Figure  12:  Quadnode  File  Representation 
H.  GENERATION  OF  NPSNET  ROADS  AND  RIVERS 

As  stated  in  Chapter  ID,  the  program  readtrrn.c  creates  the  road  and  river  data  files 
labeled  road.dat  and  riv.dat.  These  files  list  successive  x  and  z  pairs  of  grid  coordinates  for 
a  road  or  river.  A  flag  in  the  file  indicates  when  a  road  or  river  ends  and  when  the  end  of 
the  entire  file  is  reached.  In  order  to  create  the  road  and  river  polygons,  all  road  and  river 
data  must  be  grouped  as  pairs  of  successive  points.  Each  pair  of  points  is  then  converted 
into  a  multisided  polygon  with  no  more  than  six  sides  (six  is  the  limit  on  the  number  of  sides 
because  that  is  the  maximum  number  of  sides  created  when  a  two  triangles  connect  with  a 
rectangle).  The  width  of  each  polygon  is  standard  -  currently  10  meters.  The  new  road  and 
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river  polygons  are  subsequently  written  in  the  same  format  as  each  of  the  quadtree 
polygons,  which  is  described  in  Figure  12.  These  road  and  river  polygons  are  then  sorted 
according  to  their  coordinates,  and  placed  in  the  quadtree  file  containing  the  corresponding 
coordinate.  Polygon  construction  for  roads  and  rivers  is  conducted  using  the  program 
makeroads.c. 

In  the  data  set  used  in  NPSNET,  the  polygons  forming  the  roi.d  and  river  surfaces  are 
coplanar  with  the  polygons  forming  the  underlying  terrain  surface.  Therefore,  the  roads  and 
rivers  must  be  “decaled”  onto  the  terrain.  Decaling  involves  rendering  the  terrain  twice, 
thus  is  more  expensive  to  perform.  For  this  reason,  roads  and  rivers  in  NPSNET  are  only 
rendered  on  terrain  at  the  highest  resolution  [MACK  91]. 

1.  GENERATION  OF  NPSNET  CITIES  AND  TREES 

I.  A  Three>Dimensional  Interpretation  of  Two*Dimensional  Objects 

Two-dimensional  simulations  traditionally  render  trees,  cities,  vehicles  and 
other  cultural  objects  as  two-dimensional  geometric  shapes  or  icons  (e.g.  a  square  or  circle). 
In  the  JANUS(A)  model,  trees  and  cities  are  depicted  as  colored  squares.  Trees  and 
vegetation  are  colored  varying  shades  of  green,  where  the  shade  indicates  the  average 
height  of  the  vegetation  contained  in  the  area  of  the  square.  Cities  and  urban  areas  are 
rendered  in  the  same  manner,  using  varying  shades  of  yellow  to  depict  height.  The  size  of 
each  square  corresponds  directly  with  the  resolution  level  of  the  terrain  database  [JANU 
86].  Developing  a  realistic  three-dimensional  representation  from  these  two-dimensional 
squares  proposed  a  problem. 

As  mentioned  earlier,  the  NPSNET  model  currently  uses  NPSOFF  models  to 
render  cultural  objects  such  as  houses  and  trees  [ZYDA  91a].  Two  problems  arise  when 
trying  to  use  these  models  in  conjunction  with  the  JANUS(A)  database.  The  first  problem 
involves  determining  the  appropriate  number  of  single  trees  or  buildings  to  render  in  any 
given  grid  cell.  The  second  problem  is  the  unacceptable  degradation  of  the  graphics  frame 
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rate  if  the  terrain  is  even  moderately  wooded.  This  is  because  the  number  of  trees  that  need 
to  be  rendered  significantly  congests  the  graphics  pipeline. 

To  solve  the  problems  listed  above,  rendering  of  heavily  wooded  and  large  urban 
areas  is  performed  with  three  dimensional  canopies  instead  of  individual  trees  or  cities.  The 
height  of  a  canopy  is  taken  from  the  URBAN  and  VEGETATION  height  factors  extracted 
from  the  JANUS(A)  terrain  file.  The  length  and  width  of  each  canopy  is  equal  to  the 
resolution  value  (GAP)  of  the  database,  therefore,  each  canopy  covers  exactly  one  high 
resolution  grid  cell.  By  rendering  only  one  canopy  per  grid  cell,  the  number  of  polygons 
used  for  the  terrain  model  is  greatly  reduced,  allowing  an  adequate  frame  rate  in  the  model. 
To  further  increase  the  frame  rate,  the  t-mesh  function  is  used  to  draw  the  canopies. 

The  use  of  canopies  solved  the  frame  rate  problem  but  did  not  provide  a  total 
solution  to  the  problem  of  realism.  If  a  grid  cell  contains  a  tree  or  city,  together  with  a  river 
or  road,  then  the  river  or  road  would  be  covered  by  the  canopy.  The  loss  of  the  rivers  and 
roads  is  not  realistic  and  significantly  degrades  from  the  usefulness  of  the  model. 
Therefore,  a  method  was  developed  that  stochastically  rendered  individual  trees  and 
buildings,  using  NPSOFF  models,  within  a  grid  cell  that  contained  a  road  or  river  plus  a 
tree  or  city.  However,  this  random  placement  of  the  objects  causes  another  problem  by 
allowing  a  tree  or  building  to  be  placed  in  the  center  of  a  road  or  river  --  again  unrealistic. 
To  eliminate  this  phenomena,  another  algorithm  was  developed  that  checks  the  placement 
of  cultural  objects  against  the  location  of  rivers  and  roads.  If  they  coincide,  then  the  object 
is  relocated.  The  generation  of  these  cultural  objects  is  discussed  in  the  next  sections. 

2.  Generation  of  City  and  Tree  Canopies 

In  order  to  create  the  trees  and  cities,  the  information  concerning  the  presence  of 
trees  or  cities  and  the  height  of  these  cultural  objects,  that  is  stored  in  the  file  UM.ele,  is 
required.  Its  important  to  note  that  the  tree  and  city  data  applies  not  only  to  the  checkpoint 
of  assignment,  but  also  to  the  grid  cell  assigned  to  the  checkpoint.  Because  each  checkpoint 
makes  up  the  comer  of  four  different  grid  cells  (except  on  the  sides  of  the  map),  the  user 
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must  be  careful  to  properly  and  consistently  assign  the  correct  cell  to  each  checkpoint.  If 
this  assignment  is  inconsistent,  then  the  user  can  easily  lose  track  of  which  cell  should  have 
a  tree  or  city  drawn  in  it  The  JANUS(A)  convention  of  cell  assignment  is  translated  to 
match  the  NPSNET  coordinate  system  and  is  used  in  the  algorithms  discussed  next  This 
convention  assigns  each  cell  to  the  checkpoint  in  the  northwest  comer  of  the  cell. 

a.  Description  of  a  Canopy 

Each  canopy  is  composed  of  up  to  five  t-mesh  sides;  a  top,  back,  front  left, 
and  right  as  depicted  in  Figure  12.  Each  of  these  sides  is  made  up  of  two  triangles.  Two 
advantages  are  gained  from  this  triangular  design.  First,  it  allows  the  use  of  the  efficient 
SGI,  t-mesh  function.  And  second,  the  triangles  that  make  up  the  top  of  the  canopy 
correspond  directly  to  the  triangular  polygons  that  make  up  the  high  resoludon  terrain 
polygon  beneath  the  canopy.  This  correspondence  allows  the  top  canopy  to  fold  in  the 
center  in  the  same  fashion  as  the  underlying  grid  cell  providing  a  very  smooth  covering  of 
the  terrain. 


Figure  13:  Drawing  of  a  Tri-Mesh  Canopy 
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b.  Determining  the  Canopy  Height 

The  height  of  each  comer  of  the  canopy  is  determined  by  the  height  factor 
assigned  to  the  checkpoint  that  matches  the  corresponding  comer  of  the  canopy.  This  height 
factor  for  each  comer  of  the  canopy  may  be  different,  because  the  height  factor  for  each 
comer  of  the  cell  is  taken  from  the  checkpoint  directly  beneath  the  canopy  comer,  not  from 
the  master  checkpoint  for  the  cell.  If  the  checkpoint  corresponding  to  a  comer  of  the  canopy 
does  not  contain  a  tree  or  city  then  the  height  factor  is  given  the  value  of  zero  for  that  comer. 
The  assignment  of  zero  as  a  comer’s  height  factor  causes  the  canopy  to  slope  into  the 
ground. 

c.  Construction  of  Canopy  Sides 

Canopy  sides  are  not  always  drawn.  A  side  is  drawn  only  if  one  of  the 
following  criteria  are  met: 

•  The  cell,  adjacent  to  the  side  in  question,  contains  trees  or  cities  and  a  road 
or  river  passes  through  the  adjacent  cell. 

•  The  cell  just  north  of  the  current  grid  cell  does  not  contain  trees  or  cities. 

•  The  cell  just  west  of  the  current  grid  cell  does  not  contain  trees  or  cities. 

If  one  of  the  above  conditions  does  not  occur,  then  one  of  two  other  possible 
conditions  exists.  For  these  two  conditions  the  side  is  not  drawn.  The  first  non-draw 
condition  occurs  when  the  cell  adjacent  to  the  side  of  the  current  grid  cell,  contains  a  tree 
or  city  and  there  is  not  a  road  or  river  in  the  cell.  If  this  case  occurs,  the  canopy  top  will 
smoothly  connect  with  the  canopy  top  of  the  adjacent  cell.  This  decision  to  not  render  it 
reduces  the  number  of  objects  in  the  graphics  pipeline,  and  does  not  degrade  the  viewers 
image,  because  the  side  would  not  be  visible  anyway.  The  second  non-draw  condition 
occurs  when  there  are  no  trees  or  cities  in  the  cell  adjacent  to  the  southern  or  eastern  side 
of  the  grid  cell.  As  previously  mentioned,  this  case  causes  the  top  of  the  canopy  to  slope  to 
the  ground. 

In  order  to  draw  the  sides  or  top  of  a  canopy,  the  following  pieces  of  data 
must  be  present: 
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•  Elevation  for  each  checkpoint 

•  Flag  indicating  whether  a  tree  or  city  is  present  in  the  cell. 

•  Point  normals  for  the  four  checkpoints  of  the  grid  cell. 

•  Height  factor  for  the  tree  or  city. 

The  elevation,  normals,  and  world  coordinates  for  each  checkpoint  are 
stored  in  a  two-dimensional  array  called  mapgrid[i]\j].  The  indices,  i  and  j  are  the  NPSNET 
coordinates  of  the  checkpoint.  The  city  or  tree  present  flag  and  the  height  factors  for  each 
checkpoint  are  stored  in  a  separate,  two-dimensional  array  called  treecityarray{\]\}],  which 
is  created  by  the  program  maketrees.c.  A  separate  array  is  used  to  store  the  tree  and  city 
canopy  data,  allowing  the  NPSNET  combat  model  to  retain  its  flexibility  for  use  with  all 
prior  and  current  modeling  systems  that  use  the  NPSNET  platform.  The  indices  in  both 
arrays  are  intentionally  the  same  because  they  refer  to  the  same  grid  intersection. 
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Figure  14:  Order  of  Points  for  T-Mesh  Canopy  Top 
The  order  of  points  for  the  t-mesh  function  is  depicted  in  Figure  14.  This 
ordering  was  chosen  to  ensure  that  the  direction  of  the  hypotenuse  of  the  triangles  in  the 
canopy  matched  the  direction  of  the  hypotenuse  for  the  polygons  used  in  the  underlying 
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terrain  skin  (i.e.  the  hypotenuse  runs  from  the  northwest  comer  to  the  southwest  corner  of 
the  cell).  The  algorithm  to  draw  the  canopy  top  follows: 


tree_data:  is  an  array  of  float  numbers  that  contain  the  x,  y 
and  z  coordinates  of  a  point. 

/*  point  #1  */ 
tree_data[01  =  x; 

tree_data[lj  =  inapgrid[i] [ j+l] .elev  +  tree_data[2]  =  z  +  GAP; 

treecityarray [i] [j+l] .height; 
n3f (mapgridfi] [j+l] .normal) ; 
t2f (blocktreetexutre[0] ) ; 
v3f (tree_data) ; 

/*  point  #2  */ 
tree_data[0]  =  x; 

tree_data[l]  =  mapgrid[i] [ j ] .elev  +  treecityarray [ i] [j ] .height ; 

tree_data[2]  =  z; 

n3f (mapgrid[i] [ j ] .normal) ; 

t2f (blocktreetexture [3 ] ) ; 

v3f (tree_data) ; 

/*  point  #3  */ 
tree_data[0]  =  x  +  GAP; 

tree_data[l]  =  mapgrid[i+l] [j+l] .elev  + treecityarray [i+1] [j+l] .height ; 

tree_data[2]  =  z  +  GAP; 

n3f (mapgrid[i  +  1] [j  +  1] .normal) ; 

t2f (blocktreetexture [ 1] ) ; 

v3f (tree_data) ; 

/*  point  #4  */ 
tree_data[0]  =  x  +  GAP; 

tree_data[l]  a  mapgrid[ i+1] [j] .elev  +  treecityarray [i+1] [j ] .height; 

tree_data[2]  a  z; 

n3f {mapgrid[i  +  1] [j ] .normal) ; 

t2f (blocktreetexture [2] ) ; 

v3f (tree_data) ; 

endtmesh ( ) ; 

if ( flags .texturef lag)  texbind(TX_TEXTURE_0, 0) ; 


Figure  15;  Algorithm  to  Draw  the  Canopy  T-Mesh. 

The  functions  n3f ,  t2f  and  v3f,  listed  in  Figure  15,  are  SGI  library 
functions  that  bind  the  normals,  texture  and  grid  coordinates  to  a  particular  point.  The  t- 
mesh  operation  uses  these  values  to  render  the  mesh.  The  sides  of  the  canopies  are  drawn 
using  an  algorithm  similar  to  the  one  written  for  the  canopy  top  (see  Figure  14).  However, 
the  checkpoints  and  heights  vary  for  each  of  the  sides.  The  ordering  of  the  points  for  the 
side  walls,  used  as  input  to  the  t-mesh  function,  must  also  cause  the  formation  of  two 
distinct  triangles. 

The  normals  for  the  walls  are  as  follows: 
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•  back  wall  normal  (0, 0, -1) 

•  front  wall  normal  (0,0,1) 

•  right  wall  normal  (1,0,0) 

•  left  wall  normal  (-1,0, 0) 


3.  Placement  of  Individual  Trees  and  Buildings 

When  a  road  or  river  is  present  in  a  grid  cell  containing  a  tree  or  city,  individual 
trees  or  buildings  are  rendered  in  lieu  of  canopies.  The  general  description  of  a  tree  and 
building  is  illustrated  in  the  figure  below. 
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Figure  16:  Cultural  Object  Description 

The  number  of  trees  or  buildings  placed  in  a  grid  cell  is  based  on  the  height  factor 
assigned  to  the  cell  from  the  JANUS(A)  data  base.  The  exact  location  of  each  of  these 
cultural  objects  within  a  grid  cell  is  determined  randomly.  The  following  routine  ensures 
that  a  tree  or  building  is  not  placed  on  a  road  or  river.  It  accomplishes  this  by  ensuring  that 
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each  of  the  vertices  of  the  base  of  the  object,  as  depicted  in  Figure  16,  do  not  fall  inside  a 
polygon  that  makes  up  a  road  or  river. 

a.  Tree  Placement 

To  determine  whether  or  not  a  vertex  falls  inside  a  polygon,  the  following 
six-step  Tree  Placement  Algorithm  was  developed: 


Figure  17:  Polygon  Intersection  Examples 
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( 1)  Create  a  new  point  at  the  location  (0, 0)  on  the  map. 

(2)  Then  calculate  the  equation  of  the  line,  ‘L’,  that  passes  through  the  tree  base  vertex 
in  question  and  the  point  (0, 0)  using  Equation  4.7. 

(3)  Determine  the  equations  for  the  lines  that  make  up  each  side  of  the  road  or  river  polygon 
(line  Segments  AB,  BC,  CD,  DA  as  shown  in  Figure  18.). 

(4)  For  each  line  segment  of  the  road  or  river  polygon,  test  if  it  intersects  the  line  segment  ‘L’. 

(5)  Count  the  number  of  polygon  tine  segments  that  intersect  the  line  ‘L’.  If  the  count  is  even 
then  the  vertex  is  not  located  inside  the  road  or  river  polygon.  If  the  count  is  odd  the  vertex  is 
located  inside  the  road  or  river  polygon. 

(6)  If  the  segment  intersection  count  is  odd,  then  reposition  the  tree,  and  test  for  an  intersection  again. 


Figure  18:  Tree  Placement  Algorithm 
In  case  1  of  Figure  17,  the  line  segment  L  does  not  intersect  any  of  the  line 
segments  that  make  up  the  road  or  river  polygon.  Therefore  the  line  segment  intersection 
count  is  zero.  Since  ‘zero’  is  an  even  number,  vertex  (x  -  0.5,  z  -  0.5)  does  not  lie  within  the 
road/river  polygon.  In  case  2,  line  segment  L  intersects  line  segment  DA  and  no  others. 
Here,  the  line  intersection  count  is  one.  Because  the  number  ‘one’  is  an  odd  number  the 
vertex  (x  +  0,5,  z  -  0.5)  does  lie  within  the  road  or  river  polygon.  Therefore  this  tree  must 
be  relocated  and  tested  once  again  for  possible  intersection  with  a  road  or  river  polygon. 

b.  Building  Placement. 

The  placement  of  the  buildings  uses  the  tree  placement  algorithm  with  the 
following  modification.  Because  a  building  is  wider  than  a  road  it  is  possible  for  all  four 
comers  of  the  building  base  to  lie  outside  of  a  road  or  river  polygon,  while  the  middle 
portion  of  the  building  lies  inside.  Therefore,  the  tree  placement  algorithm  is  modified  to 
check  the  midpoints  of  each  line  segment  that  make  up  the  base  of  the  building  (see  Figure 
16).  This  guarantees  that  if  a  portion  of  a  building  is  set  on  a  road  or  river,  then  one  of  the 
vertices  or  midpoints  will  be  located  in  a  road  or  river. 
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c.  Equations  for  Determining  Line-Polygon  Intersections 

The  tree  placement  algorithm  is  straightforward,  but  the  equations  that 
determine  line  segment  intersections  deserve  further  mention.  First,  the  following 
equations  are  used  to  calculate  the  equations  of  the  various  line  segments. 

Line  Slope:  m  =  (Eq  4.5) 

Xj  JC' 

Y  Intercept:  b  =  (m  xxj)  (Eq  4.6) 

Line  Equation:  y  =  mx+b  (Eq  4.7) 

To  determine  whether  the  line  segment  L  intersects  any  of  the  line  segments 
of  the  road  or  river  polygon,  the  following  geometric  principles  are  required.  (The 
following  discussion  refers  to  Figure  19.)  Chose  the  points  P ,  P2  and  P3  and  the  points  P  j , 
Pj  and  P4,  where  P,  and  P2  are  the  end  points  for  line  segment  A,  and  P3  and  P4  are  the 
end  points  of  line  segment  B.  If  the  radial  direction  of  the  ordering  of  the  points,  as  listed 
above  is  not  the  same  in  both  patterns,  then  the  line  segments  must  intersect  with  each  other. 
Only  the  intersection  of  the  line  segments  would  cause  one  of  the  end  points  from  lin^. 
segment  B  to  fall  in-between  the  endpoints  of  line  segment  A,  thus  causing  the  ordering  of 
the  two  sets  of  points  to  change  form  clockwise  to  counterclockwise  or  vice  versa. 

The  same  is  true  about  the  following  two  orderings  of  the  points  P3,  P4  and 
P,  and  the  points  P3,  P4  and  Pj.  This  leads  to  the  following  proposition: 

A  necessary  and  sufficient  condition  for  two  closed  line  segments  to  cross  each 
other  is: 

[order  (Pi,P2,P3)  *  (order  (P,,P2,P4))] 

A 

[order  (P3,  P4,  Pi)  order  (P3,  P4,  Pj)  1  (Eq  4.8) 

[KAN A  91].  As  pointed  out  in  the  paper  by  Y.  Kanayama,  on  page  8  of  his 
article,  the  signs  associated  with  the  areas  of  the  triangle  formed  by  the  triples  of  line 
segment  end  points,  correspond  directly  with  the  ordering  of  the  points.  Therefore, 
Equation  4. 10  is  easily  implemented  using  the  areas  calculated  with  Equation  4.9. 
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Case  1 

/  '  P2'''x 

Case  2 
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\  1 

P3 

PI 

P3 

PI 

The  Ordering  of  P1,  P2  and  P4 
is  CCW  In  Case  #1. 

While  the  Ordering  of  PI,  P2  and  P4 

Is  CW  In  Case  #2. 

Figure  19:  Illustration  of  Line  Segment  Intersections 
The  order  function  returns  the  sign  (positive,  negative,  or  zero)  that  is 
assigned  to  the  area  of  the  triangle  formed  by  the  triple  of  points  that  are  input  to  the 
function.  The  number  ‘one’  indicates  a  clockwise  ordering,  and  the  number  ‘negative  one’ 
indicates  a  counterclockwise  ordering.  The  number  ‘zero’  indicates  that  the  points  are 
coincident  upon  the  same  line  segment. 

Area{Pi,P2,PT)  =  (^)  x  (((Jr2-Jc,)  x  (yj-y,)  -  ((xj-x,)  x  (yj-y,))))  (Eq4.9) 

(l)ifsign  (/lfea(P,,P2,P3))  >0 

Order(Pi,P2,Pj)  =  (O)ifsign  (>lrefl(P,, P2, P3))  =  0  (Eq4.10) 

(-1)  if  sign  (/tr^afP,,  P2,  P3))  <0 
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V.  NPSNET:  GENERATION  OF  A  THREE-DIMENSIONAL  SCRIPT 

This  chapter  outlines  the  procedures  required  to  create  a  script  for  the  three- 
dimensional  simulation,  NPSNET,  from  postprocessor  files  written  by  the  two- 
dimensional,  JANUS(A)  simulation.  The  major  hurdle  to  overcome  for  this  conversion,  is 
that  a  two-dimensional  game  does  not  require  (and  in  this  case,  does  not  produce)  all  of  the 
information  needed  to  define  what  a  vehicle  is  actually  doing  at  every  moment  in  the  game. 

A.  THREE-DIMENSIONAL  INFERENCE  PROBLEM 

In  the  traditional  JANUS  game,  vehicles  are  represented  on  a  two-dimensional  screen 
using  a  simple  icon.  Depending  on  whether  a  vehicle  is  classified  as  “friend”  or  “foe”,  this 
icon  is  permanently  faced  to  the  left  or  right  and  no  indication  is  given  to  its  direction  of 
travel,  its  orientation,  or  its  gun  tube/sight  orientation  [JANU  86].  As  mentioned  in  Chapter 
in,  JANUS(A)  supplies  the  following  five  types  of  postprocessor  files: 

1)  Movement  (position  of  a  vehicle). 

2)  Artillery  (location  of  indirect  fires). 

3)  Fires  (which  vehicle  shot  who). 

4)  Kills  (who  was  killed  by  whom). 

5)  Detection  (which  vehicle  detected  another  vehicle)  [JANU  86]. 

In  general  these  files  list  the  x  and  y  coordinates  of  a  vehicle  at  the  time  an  event 
occurs.  Additionally,  who  it  shot,  the  location  of  the  target,  the  location  of  impact  for  each 
artillery  shot,  and  the  clock  time  for  each  of  these  events  is  included  with  these  listings 
[JANU  86].  When  the  actual  JANUS  model  is  running,  it  is  possible,  upon  request,  to  find 
out  the  speed  of  a  vehicle  and  its  Une-of-sight  fan.  However,  this  information  is  not 
recorded  in  the  postprocessor  files. 

In  order  to  recreate  a  viable  three-dimensional  representation  of  the  game,  new 
information  about  what  each  vehicle  was  doing  between  recorded  events  must  be  inferred. 
The  C  Language  Integrated  Production  System  (CLIPS)  expert  system  shell  was  chosen  as 
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the  inference  engine  to  generate  this  new  information  [GlAR  89].  CLIPS  was  chosen 
because  of  the  considerable  amount  of  pattern  matching  that  needs  to  take  place. 

B.  APPROACH 

The  first  step  in  the  information  inference  process  is  to  determine  the  data  that 
NPSNET  requires  for  rendering.  One  of  the  capabilities  of  NPSNET  is  to  display  and  move 
vehicles  according  to  a  script.  To  read  the  script,  NPSNET  first  compares  the  current  game 
clock  with  the  time  assigned  to  the  top  element  in  the  script  file.  If  the  game  clock  is  greater 
than  or  equal  to  the  event  time,  then  the  event  is  read  and  its  instructions  are  implemented. 
To  simplify  the  processing  of  a  script,  each  line  in  the  script  file  is  considered  an  event  The 
information  contained  in  each  event  line  is  as  follows: 

•  Time 

•  Vehicle  Number 

•  Vehicle  Type 

•  X  coordinate 

•  Z  coordinate  (referred  to  as  the  Y  coordinate  in  a  2D  world) 

•  Vehicle  orientation  (in  positive  radians) 

•  Weapon  orientation  (in  positive  radians) 

•  Speed  (meters  per  second) 

•  Shot  fired  (1=  Yes;  0  =  No) 

•  Alive  (1=  alive;  0  =  killed) 

•  Elevation  (ground  vehicle  =  0;  helicopter  =  100  meters;  plane  =  200  meters) 

After  NPSNET  reads  an  event,  it  assigns  the  event  speed  and  direction  to  the  three- 
dimensional  vehicle  model.  If  the  vehicle  shoots  or  dies,  a  flash  or  burning  hulk  is  rendered 
respectively. 

C.  CREATING  THE  NPSNET  SCRIPT  FILE 

The  key  to  inferring  new  information  from  the  post  processor  files  is  to  compare  the 
current  event  with  the  chronologically  subsequent  event  for  the  same  vehicle.  From  these 
comparisons,  many  useful  pieces  of  information,  such  as  the  speed  and  direction  of 
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movement  can  be  inferred.  Currently,  events  in  the  JANUS  postprocessor  files  are  listed 
chronologically,  with  a  postprocessor  file  appearing  as  shown  in  the  following  table  [JANU 
86]: 


TABLE  4:  MOVE  POST-PROCESSOR  FILE  EXAMPLE 


TIME 

Vehicle  Side 

Vehicle 

Number 

X  Coord 

Y  Coord 

0.10 

2 

5 

345.8 

5678.9 

0.12 

1 

12 

578.5 

5478.2 

0.20 

1 

8 

566.1 

5410.0 

1.28 

2 

20 

367.2 

5554.9 

1.30 

1 

12 

577.1 

5465.7 

In  order  to  compare  two  events  for  a  single  vehicle  (e.g.  Vehicle  12,  Side  1  from  Table 
4),  there  needs  to  be  an  easy  way  to  locate  the  next  event  for  a  particular  vehicle.  Searching 
each  of  the  five  postprocessor  files  for  chronologically  subsequent  events  is  a  memory 
intensive  process  that  would  quickly  become  time  consuming  and  thus  not  useful. 
Therefore,  an  event  file  is  created  for  each  vehicle.  Next,  each  of  the  JANUS  postprocessor 
files  is  read  and  the  events  pertaining  to  each  individual  vehicle  is  stored  in  its  own  file. 
Furthermore,  a  letter  is  appended  to  the  head  of  each  event  to  identify  its  event  type  (fire, 
move,  etc.).  A  typical  vehicle  event  file  appears  below: 


TABLE  5:  EVENT  FILE  FOR  VEHICLE  12,  SIDE  1 


Letter 

Tune 

X  Coord 

Y  coord 

Target  X  coord 

Target  Y  cowd 

M 

0.12 

578.5 

5478.2 

M 

1.30 

577.1 

5465.7 

F 

2.88 

570.5 

5461.2 

458.9 

5889.7 

K 

3.5 

570.3 

5459.9 

M=  nwve',  F  =  fire',  K  =  kill',  A  =  artillery;  D  =  detection 
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With  the  events  for  eacn  vehicle  stored  in  a  single  file,  it  is  now  easy  to  read  an  entire 
vehicle  event  file  into  memory,  compare  two  chronological  events  for  a  vehicle,  and  infer 
some  useful  information  about  the  vehicle’s  activities  between  listed  events. 

D.  INFERRED  INFORMATION  REQUIREMENTS 

In  general,  there  are  three  activities  that  a  vehicle  could  possibly  perform  between 
listed  events.  It  can  be  halted,  moving,  or  killed.  In  order  to  present  a  realistic  three- 
dimensional  representation  of  these  three  activities,  the  following  pieces  of  information  are 
inferred: 

•  Orientation  of  the  vehicle 

•  Orientation  of  the  weapon  (turret) 

•  Direction  of  movement  (if  moving) 

•  Speed 

The  basic  speed  and  orientation  of  the  vehicle  and  weapon  are  obtained  by  performing 
the  simple  calculations  described  below.  The  general  mission  of  the  vehicle  is  determined 
in  order  to  gain  a  more  refined  estimate  of  its  weapon’s  orientation  and  speed.  These 
calculations  are  implemented  using  CLIPS  Object-Oriented  Language,  (C(X)L)  [GIAR 
91  j.  COOL  is  used  because  the  encapsulation  of  the  information  pertaining  to  one  object  - 
-  and  there  are  a  lot  of  information  slots  per  object  -  makes  it  easy  to  manipulate  the  object 
as  a  whole. 

E.  BASIC  CALCULATIONS 

These  simple  calculations  are  used  to  determine  basic  speeds  and  directions. 

Speed:  The  classic  equation: 

velocity  =  (Ad) /(At)  (Eq4.11) 

The  change  in  distance  is  calculated  using  the  equation  for  the  length  of  a  line  when 
two  points  are  known: 

4  4=  J(X„„,-XcurreJ  +  " /currm,)  (Eq  4.12) 
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The  change  in  time  is  calculated; 

^‘  =  ‘n..,-‘curr..,  (Eq4.13) 

Orientation  (  0  ); 

To  determine  the  angle,  0,  take  the  arc  tangent  of  the  quotient  of  the  difference 
between  the  y  coordinates  and  the  x  coordinates. 


angle:  0  =  arctan  (Eq4.14) 

^curentx 

Once  0  is  determined,  then  the  quadrant  (using  the  Cartesian  Coordinate  System)  is 
found  by  analyzing  whether  the  difference  in  the  x  and  z  coordinates  are  positive  or 
negative. 

Then  these  values  are  used  to  access  the  following  table,  which  gives  the  quadrant 
factor.  This  factor  is  added  to  0  to  produce  the  actual  orientation  of  the  vehicle  (All  angles 
are  measured  using  the  x  axis  as  the  base  or  zero  axis,  with  clockwise  as  positive  rotation. 
All  calculations  are  in  radians.). 

TABLE  6:  ANGLE  OF  ORffiNTATlONS  QUADRANT  FACTORS 


sign  X  coord 

sign  z  coord 

quadrant 

factor 

+ 

+ 

0.0 

+ 

- 

2n 

- 

- 

n 

- 

+ 

n 
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F.  THE  HEURISTIC  MODEL 

There  are  two  types  of  missions  that  a  vehicle  may  be  assigned.  They  are  the  classic 
defensive  or  offensive  missions.  Determining  which  mission  a  vehicle  is  assigned  assists  in 
the  inference  of  information  between  events.  The  different  heuristics  are  explained  next. 

1.  Defensive  Heuristic 

There  are  several  characteristics  that  suggest  that  a  vehicle  is  in  a  defensive 
posture.  The  primary  or  tell-tale  defensive  characteristic  is  when  a  vehicle  is  travelling  at  a 
speed  of  less  than  3  k.p.h.  This  speed  tends  to  suggest  that  the  vehicle  is  either  on  an 
extremely  slow  and  deliberate  offensive  mission  or  it  is  really  sitting  still  (in  a  defensive 
position)  for  most  of  the  time  interval  between  the  two  listed  events.  If  it  moves  to  its  next 
position  at  a  more  deliberate  speed  of  about  13-15  k.p.h.,  it  is  assumed  that  it  is  moving  to 
an  alternate  defensive  position.  If  this  extremely  slow  speed  is  encountered,  there  are  two 
other  pieces  of  evidence  that,  if  present,  tend  to  confirm  the  defensive  hypothesis.  One  of 
these  additional  pieces  of  evidence  is  whether  the  vehicle  just  completed  firing  a  shot  or 
will  fire  a  shot  in  the  future.  This  tends  to  be  true  because  a  vehicle  shooting  on  the  move 
would  normally  be  travelling  at  a  speed  much  in  excess  of  3  k.p.h.  if  it  wants  to  survive. 
The  second  piece  of  evidence  assumes  that  if  a  vehicle  fires  in  the  future,  and  if  the  distance 
to  the  next  firing  position  is  less  than  100  meters,  it  is  probably  moving  between  fighting 
positions  and  hence  is  in  a  defensive  posture.  If  all  of  the  above  conditions  are  met  then  the 
program  asserts  that  the  vehicle  is  in  the  defense,  and  as  a  consequence  halts  the  vehicle 
and  orients  it  towards  the  enemy  (towards  the  next  target  location).  Then,  the  vehicle  moves 
to  its  next  event  location  at  a  set  speed  of  13  k.p.h.,  ensuring  that  it  arrives  at  the  next  event 
location  on  time.  There  are  certainly  other  heuristics  that  can  suggest  if  a  vehicle  is  in  the 
defense  or  not;  they  currently  are  not  implemented. 

A  second  tell-tale  heuristic  is  whether  a  vehicle  does  not  move  for  over  five 
minutes.  Not  moving  for  over  five  minutes  suggests  that  the  vehicle  is  in  a  defensive 
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posture  "  viewing  the  engagement  area.  Then  at  a  certain  time  it  would  move  quickly  to  its 
next  defensive  position. 

2.  Offensive  Heuristic 

Its  assumed  that  if  a  vehicle’s  events  do  not  confirm  the  defensive  heuristic  then 
the  vehicle  is  considered  to  be  on  an  offensive  mission.  This  is  a  simple  but  rather  accurate 
hypothesis  but  does  not  exhaust  the  need  for  other  inferred  knowledge. 

3.  Speed  Smoothing  Heuristic 

An  anomaly  that  becomes  very  apparent  in  a  three-dimensional  world,  that  is  not 
readily  observed  in  the  two-dimensional  JANUS(A)  simulation  is,  at  times,  a  vehicle 
travels  at  a  speed  in  excess  of  45  m.p.h.  Unless  the  vehicle  is  an  aircraft,  this  is  very 
unrealistic,  and  probably  due  to  minor  modifications  in  input  by  the  user  at  the  time  of  the 
original  JANUS(A)  run.  This  anomaly  often  occurs  between  the  initial  position  for  a 
vehicle  and  the  first  event  listed  in  the  postprocessor  files. 

If  these  two  conditions  occur,  then  at  start  time,  the  vehicle  is  rendered  at  the 
position  specified  by  the  first  movement  rather  than  the  location  specified  by  the  initial 
conditions.  It  is  also  given  a  speed  of  zero.  If  this  excessive  speed  anomaly  does  not  occur 
between  the  initial  position  and  the  first  event,  then  the  speed  is  smoothed. 

The  smoothing  algorithm  slows  the  speed  of  the  vehicle  to  25  k.p.h.  This  decrease 
in  speed  has  a  natural  side  effect.  It  will  cause  the  vehicle  to  not  be  at  the  correct  location 
when  its  next  event  is  scheduled  to  occur  (call  this  upcoming  event.  A).  To  compensate  for 
this  problem  a  new  MOVE  event  is  created  (event  B)  which  will  keep  the  vehicle  moving 
at  a  speed  of  25  k.p.h.  to  the  location  that  was  specified  in  event  A.  In  order  to  get  the 
vehicle  back  in  synchronization  with  the  remainder  of  the  event  list,  the  speed  associated 
with  moving  from  event  A  to  its  subsequent  event  is  increased  to  allow  the  vehicle  to  arrive 
at  the  follow-on  event’s  location  on  time. 
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4.  Vehicle  Orientation  Heuristic 

As  a  rule,  the  orientation  of  the  vehicle,  if  moving,  is  always  in  the  direction  of 
travel.  If  the  vehicle  is  halted,  the  orientation  depends  on  the  following  pieces  of  evidence: 

(1)  If  the  vehicle  is  firing  during  the  current  event  then  orient  towards  the 
target 

(2)  If  the  vehicle  is  not  firing  but  will  fire  in  the  future,  orient  the  vehicle 
towards  the  next  target  location. 

(3)  If  the  vehicle  is  not  firing  and  will  not  fire  in  the  future,  then  use  the 
vehicle  orientation  from  the  last  event  as  the  current  orientation. 

(4)  If  the  vehicle  is  placed  on  the  battlefield  but  does  not  have  any  events 
associated  with  it,  then  orient  the  vehicle  in  its  initial  view  direction. 

5.  Weapon  Orientation  Heuristic 

The  heuristics  for  weapon  orientation  are  similar  to  those  used  for  the  vehicle 
orientation  with  a  few  differences. 

(1)  If  the  vehicle  is  firing  during  the  current  event  then  orient  the  weapon 
towards  the  target. 

(2)  If  the  vehicle  is  not  firing  but  will  fire  in  the  future,  orient  the  weapon 
towards  the  next  target  location. 

(3)  If  the  vehicle  is  not  firing,  will  not  fire  in  the  future,  but  did  fire  in  the  past 

then  use  the  weapon  orientation  from  the  last  firing  event  as  the  new 
weapon  orientation. 

(4)  If  the  vehicle  never  fires  then  orient  the  weapon  in  the  same  direction  as 
the  vehicle. 

G.  CALCULATION  OF  THE  HEURISTICS  IN  CLIPS 

Using  the  CLIPS  Object  Oriented  Language  (COOL),  each  of  the  events  listed  in  a 
vehicle  event  file  is  read  into  one  of  the  following  objects:  MOVE,  FIRE,  KILL,  ARTY.  It 
should  be  clear  as  to  which  type  of  event  is  stored  in  which  object  [GIAR  91].  After  the 
entire  file  is  read  into  memory,  then  each  event  is  compared  against  the  next  event  or  an 
upcoming  firing  event.  These  comparisons  generate  facts  that  are  stored  in  the  form  of 
(condition,  <fact>).  Then,  based  on  the  facts  generated,  CLIPS’  inference  engine  will 
choose  the  appropriate  rule  to  execute.  These  rules  call  methods  and  functions  which 
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generate  the  data  required  for  NPSNET  [CLIP  91].  Table  7  lists  the  combinations  of  facts 
that  CLIPS  uses  in  determining  the  conect  rule  to  use.  Once  a  rule  is  chosen  and  the 
NPSNET  event  data  is  generated,  this  data  is  written  to  a  file  specified  for  the  current 
vehicle. 

Once  the  event  file  for  all  of  the  vehicles  is  evaluated,  each  of  the  files  containing  the 
heuristic  data  is  combined  into  a  single  event  list  file  and  labeled  janusscript.dat.  This 
single  file  is  then  sorted  chronologically.  After  sorting  it  is  ready  to  be  used  by  NPSNET 
as  a  script  file. 


TABLE  7:  VEHICLE  STATE  CONDITIONS 


Primary 

activity 

Prior 

shot 

Post 

-shot 

S 

n 

speed 

> 

45 

kph 

31cph 

< 

speed 

< 

45 

speed 

< 

3kph 

speed 

0.0 

kill 

Dist 

to 

fire 

<.lkm 

Dist 

to 

fire 

>.l  km 

Time 
to  next 

event 

>5  min 

Halt 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

DC 

Halt 

no 

no 

no 

no 

no 

no 

yes 

no 

DC 

DC 

DC 

Halt 

yes 

no 

no 

no 

no 

no 

yes 

no 

DC 

DC 

DC 

Halt 

DC 

yes 

no 

no 

no 

no 

yes 
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TABLE  7:  VEHICLE  STATE  CONDITIONS 


Primary 

activity 

Prior 

shot 

Post 

-shot 

H 

speed 

> 

45 

lq}h 

3kph 

< 

speed 

< 

45 

speed 

< 

3kph 

speed 

0.0 

kiU 

Dist 

to 

fire 

<.lkm 

Dist 

to 

fire 

>.l  km 

Time 

to  next 

event 

>5  min 

Move 

DC 

yes 

yes 

no 

no 

yes 

no 

no 

yes 

no 

yes 

Move 

DC 

no 

yes 

no 

no 

yes 

no 

no 

no 

no 

yes 

Note:  Not  every  permutation  of  conditions  was  considered  meaningful.  The  code  DC  (don't  care) 
is  used  to  identify  conditions  that  are  not  meaningful. 
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VI.  NETWORKING  AND  REAL  TIME  SIMULATION 

A.  JANUS(A)  FOR  THE  UNIX  OPERATING  SYSTEM 

1.  Background 

The  U.S.  Army  realized  the  advantages  of  running  the  JANUS(A)  combat  model 
on  the  popular  and  compact  UNIX  based  workstations  instead  of  on  the  cumbersome  VAX/ 
Tektronix  systems  currently  in  use.  In  August  of  1991,  TRAC  Monterey  contracted  with 
the  Rand  Corporation  to  develop  a  version  of  JANUS(A)  that  would  operate  on  a  Sun/ 
UNIX  workstation.  Jim  Guyton,  of  Rand,  delivered  a  working  prototype  of  JANUS(A)  for 
UNIX  in  AprU  1992  [GUYT  92]. 

The  goal,  and  most  exciting  part  of  this  research,  was  the  question  of  developing 
a  real-time,  network  link  between  the  traditional  JANUS  (A)  model  and  NPSNET.  In  the 
past,  this  was  not  feasible  because  of  the  drastically  different  protocols  and  platforms.  With 
the  introduction  of  the  new  version  of  the  JANUS(A)  combat  model,  it  finally  became 
possible  to  construct  this  real-time  network. 

2.  Contrasts  Between  the  UNIX  and  VAX  Versions  of  JANUS(A) 

This  new  UNIX-based  version  of  JANUS(A),  which  is  called  JANUS(X),  does 
not  change  the  “inner- workings”  of  the  original  combat  model.  The  model  itself  is  identical 
in  both  versions,  in  fact,  the  same  FORTRAN  code  is  used  in  both  models.  This  reuse  of 
the  V AX-FORTRAN  code  is  made  possible  by  the  Sun  4-FORTRAN  compiler,  which  is 
capable  of  translating  VAX  data  types  and  system  calls  into  their  UNIX  equivalents  [SUN 
91]. 

The  only  viable  difference  between  the  two  versions  of  JANUS  is  that  the  UNIX 
version  bypasses  all  FORTRAN  calls  to  the  Tektronix  screens,  and  replaces  then  with  the 
‘C’  programming  language  calls  to  the  X-Windows  environment  [GUYT  92].  Also,  much 
like  the  converted  Hies  mentioned  in  Chapter  II,  the  input  data,  such  as  the  force  and  system 
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files,  are  translated  into  a  file  format  that  is  compatible  with  the  UNIX  operating  system 
[GUYT92]. 

3.  JANUS(X)  Networking  Capabilities 

As  mentioned  above,  the  VAX-version  of  JANUS(A)  is  hindered  by  its 
antiquated  hardware  and  non-networking  capabilities.  This  version  can  only  be  displayed 
on  Tektronix  monitors,  with  the  Blue  force  on  one  screen,  and  the  Red  force  on  another  as 
shown  in  Figure  20. 


Figure  20:  The  Traditional  JANUS  (A)  Hardware  Setup. 

JANUS(X),  on  the  other  hand,  has  the  added  flexibility  of  being  run  on  a  Sun 
Workstation  with  the  display  piped  to  the  same  monitor,  or  any  other  workstation  and 
monitor  with  X-Windows  capability  as  shown  in  Figure  21. 
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Figure  21:  Networking  Capabilities  of  JANUS(X) 

The  communications  between  the  Sun  Workstation,  running  the  JANUS(A) 
simulation,  and  the  workstations  rendering  the  two-dimensional  images  is  accomplished 
using  an  Ethernet  network.  JANUS  (X)  creates  messages  and  places  them  on  the  network 
as  packets.  These  message  packets  are  read  by  a  listening  workstation  and  rendered 
appropriately  on  its  monitor  [GUYT  92]. 

JANUS(X)  executes  two  different  programs  at  the  same  time.  The  main 
JANUS(X)  program  operates  on  one  Sun  workstation.  This  program  executes  all 
operations  of  the  JANUS(A)  combat  model,  initializes  the  network,  and  sends  the  message 
packets  to  the  network.  The  messages  are  prepared  using  the  functions  found  in  the  sub- 
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program  ct.c,  located  in  the  janusIsunlXgrctf  directory.  The  second  program  is  called  xtest, 
located  in  the  janus/sun  directory.  This  program  runs  on  the  workstation  that  will  render  the 
X'Windows  screens.  Xtest  captures  the  message  packets  that  are  on  the  network,  then  sends 
them  to  the  sub-program  parse.  Here,  the  messages  are  returned  to  their  original  function 
formats,  which  are  defined  in  the  sub-program  ct.c  (Note:  There  are  two  programs  named 
ct.c.  The  one  in  the  JANUS(X)  directory,  janusIsunIXgrcrf,  creates  messages.  The  other 
one,  in  the  second  workstation’s  directory, reads  the  messages.).  The  functions 
in  janus/sun/ ct.c  call  the  X-Windows  library  functions  required  to  render  the  two- 
dimensional  images  on  the  monitor.  Additionally,  screen  inputs  to  JANUS  (e.g.  mouse 
picks)  are  captured  by  xtest,  recorded  into  a  message  packet,  and  sent  back  to  the  machine 
running  the  main  JANUS  model  [GUYT  92]. 

4.  Network  Message  Format 

NPSNET  and  JANUS(X)  use  two  different  message  sending  protocols,  and 
consequently,  use  different  message  formats.  To  accommodate  both  functions,  messages 
are  first  sent  from  the  JANUS(X)  game  using  its  own  format.  When  these  messages  are  read 
by  the  program  xtest.c  on  the  receiving  IRIS  workstation,  they  are  changed  to  the  NPSNET 
message  format  Then,  they  are  transmitted  to  the  program  network.c  on  the  receiving  IRIS 
workstation. 

a.  JANVSiX)  Message  Format 

The  program  Xgrctf/ct.c  has  the  important  task  of  preparing  packets  to  send 
across  the  network.  Each  of  these  packets  contain,  among  other  things,  the  specific  graphics 
function  calls,  which  are  used  to  display  the  battle  on  a  ‘listening’  monitor.  Each  of  these 
message  producing  procedures  has  two  common  elements,  besides  the  function  itself.  First, 
each  screen  (red  force  and  blue  force)  has  a  unique  file  pointer,  referred  to  as  a  “screen 
pointer’’,  assigned  to  it.  The  variable  containing  the  address  of  the  screen  pointer  is  labeled 
gr_out  as  shown  in  Figure  22.  Additionally,  JANUS(X)  stores  the  number  of  the  screen 
currently  being  addressed  in  the  global  variable  ramtekJjS]-,  which  is  either  the  integer 
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“one”  or  “two”  referring  to  the  blue  or  red  screen  respectively.  Secondly,  every  object 
displayed  on  the  screen  is  assigned  a  unique  identifier.  This  identifier,  an  integer  value,  is 
referred  to  as  the  segment  number  as  depicted  in  Figure  22  [GUYT  92].  This 
segment  number,  which  is  key  in  rendering  the  appropriate  item  on  the  monitor,  can  be 
anything  from  a  tactical  vehicle  to  a  line  that  makes  up  a  border  of  the  screen.  Another  piece 
of  important  information,  often  included  in  a  message,  is  the  grid  coordinate  for  the  object 
referenced  in  the  message. 

When  the  JANUS(X)  program  calls  one  of  the  functions  in  the  subprogram 
Xgrapct.c,  the  name  of  the  function,  along  with  a  list  of  arguments  representing  appropriate 
drawing  commands,  are  passed  to  the  function  ct jjrm/fas  illustrated  in  Figure  22.  When 
called,  the  ct jjrintf  function  places  the  set  of  arguments  from  the  message  into  a  queue 
named  va  args.  When  this  argument  queue  reaches  a  total  of  80  arguments,  the  queue  is 
packaged  into  one  message  packet  and  placed  on  the  network.  As  mentioned  above,  the  80 
argument  message  packet  is  received  by  xtest,  then  parsed  into  the  original  set  of  function 
calls.  All  integer  and  real  numbers  are  passed  by  reference  with  in  the  JANUS  (X)  program. 
However,  these  same  integer  and  real  numbers  are  passed  by  value  within  the  message 
packets. 


Segment  Number:  unique  to  each  object 


Map  Coordinates  of  segment/object 

- - - - 

II^-— — "  Jtc''' 

ct_call_segment_(segment_number,  posjtion_x,  position_y,  attributesjlag) 
int  *segment_number; 

int  *posilion_x:  /*  position  is  really  1  parameter  of  type  XY+  */ 
int  •position_y: 

int  ’attributesjlag:  _ Library  Function  Reference 


{ 


fprintf(gr_out,  "ct_call_segment.  %d.  %d.  %d,  %d\n”, 


} 


*segment_numbfcr,  ’position_x,  *position_y,  ’attributesjlag); 


Screen  Pointer 


Figure  22:  JANUS(X)  Network  Message  Example 
h.  NPSNET  Message  Format 

The  NPSNET  network  protocol  is  simpler  than  that  used  by  JANUSQC). 
Messages  consist  of  a  lead  character,  followed  by  a  set  of  integer  and  real  number 
arguments  as  shown  in  Figure  23.  The  lead  character  is  used  in  the  parsing  process  to 
indicate  to  which  message  function  the  incoming  message  belongs.  The  definition  of  the 
lead  characters  of  the  messages  are  defined  in  tlie  file  network.h  of  the  NPSNET  program. 
Instead  of  batch  messages,  NPSNET  packages  each  message  individually,  using  the  ‘C’ 
sprintf  function.  The  message  is  then  placed  on  the  network  using  the  function 
putmessonnet,  found  in  the  program  janusisunict.c. 

The  NPSNET  sub-program  network  parses  all  incoming  messages  using  the 
lead  character  of  the  message  as  the  key.  Once  parsed,  the  message  is  passed  to  the 
appropriate  function  in  NPSNET. 
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ct_send_vehjire_{numunit,  numside,  tgtunit,  tgtside) 
int  *numuntt: 
int  *numside: 
int  *tgtunit: 
int  ‘t^side; 

char  message[MESSAGELENGTHl; - ^6^^,  Character 

sprintf(message,”7oC  7od  7od  7od  7od'’ 

JANFIREMESS,  'numunit,  *numside,  ‘tgtunit,  ‘tgtside); 
putmessonnet(message): 


B.  N.'  -NET  MESSAGES  FROM  JANUS 

1.  General  Message  Translation  to  NPSNET  Format 


a.  Segment  Number  Conversion 

The  segment jtumber  uniquely  identifies  every  object  that  JANUS(X) 
wants  drawn.  The  blue  force  vehicles  are  assigned  the  segment  numbers  between  600  and 
1 199,  and  the  red  force  vehicles  are  assigned  segment  numbers  from  1200  to  1799.  The  use 
of  this  “single-number”  identifier  presents  a  problem,  because  the  remainder  of  the 
JANUS(X)  model  uses  a  “two-number”  identifier  {force  side  and  vehicle  number)  to 
identify  a  vehicle.  However,  because  the  starting  index  for  each  force’s  vehicles  is  known, 
as  well  as  the  length  of  the  segment  of  numbers  assigned  to  the  blue  and  red  vehicles,  it  is 
possible  to  calculate  the  force  side  index  and  the  vehicle  number.  To  calculate  ihc  force  side 
index,  divide  the  segment_number  by  600  using  integer  division  as  described  in  Equation 
5.1.  To  calculate  the  vehicle  unit  number  index,  take  the  modulus  of  the  segment_number 
base  600  as  shown  in  Equation  5.2. 

Side  =  (Segment_Number)div  (600)  (Eq5.1) 

UnitNumber  =  (Segment_Number)  mod  (600j  (Eq  5.2) 


b.  Grid  Coordinate  Translation 

Recall  that  JANUS(X)’s  origin  for  its  coordinate  system  is  situated  at  the 
lower-left  hand  comer  of  the  map.  Also,  the  origin  is  not  labeled  (0,  0),  but  is  labeled 
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according  to  the  UTM  coordinates  assigned  to  this  point  in  the  world,  in  kilometers. 
NPSNET,  on  the  other  hand,  has  its  origin  in  the  upper-left  hand  comer  of  the  map,  and 
references  this  location  by  the  coordinates  (0,  0).  Also,  NPSNET  measures  distance  in 
meters  not  kilometers.  Therefore,  for  NPSNET  to  recognize  the  JANUS(X)  coordinates 
these  coordinates  must  be  translated  to  the  NPSNET  system  format.  To  further  complicate 
matters,  JANUS(X)  masks  the  thousands  digit  of  each  coordinate  in  order  to  save  room  in 
memory.  This  digit  must  be  reconstructed  for  NPSNET’s  use. 

In  the  JANUS(A)  terrain  file,  the  map  origin’s  UTM  coordinates 
(coordinates  of  the  lower-left  hand  comer  of  the  map)  are  specified  in  their  entirety,  thus 
providing  the  information  needed  to  restore  the  thousands  digit.  Dividing  each  UTM  origin 
coordinate  by  1000,  using  integer  division,  reconstmcts  the  value  of  the  thousands  digit. 
Multiplying  this  value  by  1000  yields  a  value  which,  when  added  to  the  JANUS  x  and  z 
coordinates,  provides  the  entire  UT’M  coordinate  (see  Equation  5.3  and  Equation  5.4). 
Once  the  thousands  digit  is  restored  to  each  of  the  JANUS  grid  coordinates,  these 
coordinates  are  transposed  to  the  NPSNET  system  using  Equation  5.5  and  Equation  5.6. 

^JANUS.UTM  “  1  (X-Ongin^^^yj/IOGO)  +  lOCX)] (Eq  5.3) 

1^JANUS_CTM  ~  1  (T_0nginy^^yj/1000)  +  1000]  (Eq  5.4) 

^NPSNET  ~  (^JANUS.LTM  ~  ^  ^-5) 

^NPSNET  ~  Height_of_Map  —  [  (yjANus.uTM  ~  T_C)nginy^^[;j)  x  1000]  (Eq  5.6) 
c.  Vehicle  Model  Identification 

Once  a  segment  number  is  identified  as  belonging  to  a  vehicle,  its  vehicle- 
type  or  system-type  is  determined  (i.e.  tank,  tmck,  etc.).  JANUS(A)  references  the 
attributes,  which  includes  the  system-type  pertaining  to  a  particular  vehicle  n^ing  a  two 
tiered  system.  The  first  tier  refers  to  a  data  stmcture  called  systype.  Systype  is  a  two- 
dimensional  array  that  contains  the  name  and  other  characteristics  of  a  particular  system 
(JANUS  refers  to  a  weapon  or  vehicle  as  a  “system”).  The  first  index  into  the  systype  array 
is  the  force  side  of  a  particular  type  of  vehicle  (e.g.  MlAl  tank  may  have  the  force  side 
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index  “one”,  while  a  BMP  may  have  the  force  side  index  of  “two”).  The  second  index, 
referred  to  as  numtype,  is  a  value  between  0  and  49  inclusive,  that  selects  the  specific 
vehicle  type  in  question,  (e.g.  A  tank  may  have  the  index  of  five  and  a  fuel  truck  the  index 
of  nine.).  Once  chosen,  these  systems  characteristics  are  stored  in  the  systype  data  structure. 

The  second  tier  in  the  vehicle  identification  process  refers  to  a  structure 
named  unitsdata.  Unitsdata  is  another  global,  two-dimensional  array.  This  array  uses  the 
force  side  number  of  a  vehicle  and  its  vehicle  identification  number  as  indices.  This  array 
contains  the  numtype  for  each  vehicle,  which  is  needed  to  index  into  the  systype  array  and 
ultimately  identifying  the  vehicle’s  system-type.  Figure  23  illustrates  the  indexing 
technique  required  to  identify  a  vehicle’s  system-type. 


numtype  =  unitdata[force_side][vehicle_number] 
system  type  =  sysdata[force_side]  [numtype] 
vehicle jype  =  systemtype 

Figure  23:  Vehicle  Type  Identification 
(L  Elimination  of  Multiple  Update  Commands 

JANUS(X)  creates  two  separate  screen  images  --  one  for  the  blue  force  and 
one  for  the  red  force.  Initially,  vehicles  that  belong  to  each  force  are  only  rendered  on  the 
screen  assigned  to  the  owning  force.  However,  as  a  vehicle  of  an  opposing  force  arrives  at 
a  position  on  the  map  that  enables  it  to  observe  some  of  the  opposite  force’s  vehicles,  then 
these  observed  vehicles  are  rendered  on  both  screens.  This  means  that  two  identical 
graphics  messages  are  sent  across  the  network,  indicating  that  the  same  image  be  rendered 
once  on  each  screen.  If  the  identical  update  messages  are  sent  twice,  NPSNET  will  try  to 
update  the  image  twice.  Therefore,  the  side  of  the  vehicle  is  checked  against  the  number  of 
the  screen  it  is  assigned.  If  the  side  and  screen  number  do  not  match,  then  that  update 
message  is  not  passed  to  NPSNET  as  illustrated  in  Figure  24. 
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ct_deiete_segmeiit_(segment_number) 
int  *seginent_number. 


int  *nuinunit,  *numside,  ’"screen; 
float  '"vehview; 

float  xaddedamount,  zaddedamounu 
double  ‘xu,  *yu;  /*  x  and  y  coordinates  *! 


t*  blue  units  go  from  600  to  1199  and  red  units  go  from  1200  to  1799  ■*/ 

’"numunit  =  ’"segment_number%600; 

/*  blue  is  1  red  is  2  •/  Reconstruct  Side  and  Unit  Indices 

■"numside  =  ’*segment_number/600; 


/*  displaying  on  red  or  blue  screen?  •/ 
■"screen  =  ramtek_(0]: 


Check  For  Duplicate  Message 


/*  only  kill  a  vehicle  if  it  is  killed  on  its  own  screen  ’*/  _ j 

if(('"numside  *=  1  &&  ’"screen  =  2)  II  (’"numside  =  2  &&  ’"screen  ==  1))  { 

xaddedamount  =  (float)((int)MAPXORIGIN/1000)  ■"  1CM2M;  Reconstruct 
zaddedamount  =  (float)((int)MAPZORIGINhOOO)  ■"  KM2M:--*—'  Thousands  Digit 

/*  get  X  and  y  values  and  convert  to  npsnet  values  ■"/ 

/*  unitsdata.  is  a  fortran  common  block  */ 

■•xu  =  unitsdata_.xunit[’"numside-l][*numunit-l]:  j 

■"xu  =  (’"xu  +  xaddedamount  -  MAPXORJGIN)  ■"  KM2M: 


♦yu  =  unitsdata_.yunit['"numside-l][’"numunit-l]; 

*yu  =  (“"yu  +  zaddedamount  -  MAPZORiGIN)  *  KM2M; 


"yu  =  (ZTALL*KM2M)  -  ’"yu; 


Transpose  Coordinates 
to  NPSNET  Coordinates 


t*  get  view  direction  and  convert  to  npsnet  values  */ 

■"vehview  =  direct_.dview[’*numside-l](’"numunit-l]; 
*vehview  =  TWOPI  -  "vehview; 

/"  send  kill  message  to  npsnet  ■"/ 

fprintf(gr_out,  "ct_get_veh_kill_mess,  %d,  %d,  %f.  %f.  %Ni", 
■"numside,  ’"numunit,  '"xu,  ’"yu,  "vehview); 

fprintf(gr_out,"ct_delete_segment,  ^idSn",  "segment_number); 


NPSNET 

Message 

JANUS(X) 

Message 


Figure  24:  Sample  Network  Message  Code 

2.  NPSNET  Initialization 

In  order  for  NPSNET  to  read  a  JANUS (X)  message  and  identify  the  specified 
vehicle  in  the  NPSNET  world,  the  vehicle  array  in  the  NPSNET  system  must  be  initialized 
as  described  in  Chapter  IV.  To  complicate  this  initialization  process,  JANUS(X)  does  not 
send  any  special  initialization  messages  across  the  network.  Therefore,  there  is  not  a  one- 
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to-one  message  correspondence  capable  of  providing  the  information  needed  to  initialize 
NPSNET’s  vehicle  array.  However,  two  observations  concerning  JANUS(X)  provide  the 
capability  to  accomplish  this  initialization.  The  first  being  that  JANUS(X)  begins  game 
play  by  drawing  all  vehicles  to  the  screen  once.  The  second  is  that  there  is  one  unique 
message  that  JANUS(X)  sends  just  as  game  play  commences,  called  x  enable  gin.  Using 
these  facts,  the  initialization  process  is  started  by  sending  NPSNET  the  message 
ct  getjnit  veh  mess  every  time  JANUS  calls  its  own  vehicle  update  message  function, 
ct  set  segment _position.  This  initialization  message  is  further  flagged  by  a  condition 
clause  that  checks  to  see  if  JANUS  has  scniihcx  enable  gin  message,  lix  enable  gin  was 
sent,  then  the  boolean  value,  start  boolean,  is  set  to  true  causing  the  initialization  messages 
to  be  replaced  with  vehicle  update  messages. 

Upon  receipt  of  an  initialization  message,  NPSNET  assigns  the  incoming 
vehicle  an  NPSNET  identification  number  referred  to  as  vehnum.  The  identification 
number  is  then  stored  in  a  two-dimensional  array  called 
janus2npsveharray[si<ie][unit_n\imhcT],  where  the  indices  into  the  array  are  the  JANUS 
force  side  and  unit  number  of  a  vehicle.  This  new  array  is  used  to  cross  reference  between 
the  JANUS  indices  for  a  vehicle  and  the  NPSNET  index  for  a  vehicle  as  shown  in  Figure 
25.  The  initialization  message  contains  two  other  important  pieces  of  information.  First  the 
vehicle  type,  referred  to  as  iconnumber  in  the  code,  is  sent.  NPSNET  uses  the  iconnumber 
to  lookup  the  NPSOFF  model  type.  The  table  named  janicontable  contains  the  NPSNET 
model  numbers.  This  model  number,  is  then  assigned  as  the  vehicle  type  or  vehtype  of  the 
vehicle.  The  other  important  piece  of  information  sent  in  the  message  is  the  x  and  z 
coordinates  of  the  vehicle.  These  values  are  recorded  in  the  vehpostype  structure  assigned 
to  the  vehicle.  (The  vehpostype  structure  was  discussed  in  Chapter  IV.) 

Upon  initialization,  all  vehicles  are  set  “alive”  with  a  speed  of  zero.  The  control 
of  the  vehicle  is  set  to  SAF,  indicating  that  the  vehicle  will  receive  all  of  its  updates  from 
the  network.  The  y  coordinate  (elevation  above  sea  level)  for  the  vehicle  is  set  to  zero. 
NPSNET  will  calculate  the  vehicles  true  elevation  using  a  function  called  groundjevel 
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during  execution  of  the  graphics  loop.  If  the  NPSNET  function,  isaircraft,  determines  that 
the  vehicle  is  an  aircraft  then  the  vehicle’s  elevation  above  the  terrain  is  calculated  using 
the  movetheaircrqft  functions. 


getianusinttmessimessage) 
cnar  messageQ;  rincoming  message*/ 


{ 


stoict  vehpostype  tempveh; 

int  iconnumber;  Tthe  Janus  icon  number  */ 

int  janside;  /*the  side  of  the  Janus  vehicle  */ 

int  janvehnum;  /*the  vehicle  unit  number  for  Janus  */ 


if(networkvehiclesin  ==  FALSE)  networkvehiclesin  =  TRUE; 
r  Increment  the  total  number  of  vehicles  read  in  for  JANUS  in  NPSNET  */ 
jannumvehs-t-t-; 

-  Incoming  Message  Format 

sscanf(message,  "%d  %d  %f  %f  %f  %d", 

&{anside,  &ianvehnum,  &tempveh.pos[X],&tempveh.pos[Z], 

&tempveh.direction,  &iconnumber); 

r  Set  the  new  vehicle’s  index  in  the  lookup  table  number  */  JAWS  to  NPSNET 

jan2npsveharraytjanside][janvehnuml  =  jannumvehs;  —  Cross  Index  Array 

/*  initialize  the  NPSNET  vehtype  values  */ 
tempveh.vehtype  =  janicontableficonnumber]; 
tempveh.jan_t^e  » iconnumber; 
tempveh.viewdirection  =  0.0; 
tempveh.speed  =  0.0; 
tempveh.alive  =  1 ; 
tempveh. pos(Y]  =  0.0; 
tempveh.behavoir  =  SAF; 
tempveh.undriven_control  =  SAF; 

if  (canshootftempveh.vehtype))  tempveh.rounds  =  100; 
else  tempveh.rounds  «  0; 


r  If  the  vehicle  is  an  aircraft  place  it  100  meters  above  the  ground  */ 
if(isaircraft(tempveh.vehtype)) 
tempveh.elev  =  100; 
else  tempveh.elev  =  0.0; 

r  Place  the  new  vehicle  in  the  vehicle  array  */ 
veharraynannumvehs]  =  tempveh; 
veharrayuannumvehsj.vehnum  =  jannumvehs; 


Figure  25:  NPSNET  Initialization  Message  Function 

3.  Vehicle  Movement  Updates 

The  JANUS(X)  message  ct  set  segment _postion  is  used  to  update  the 
movement  of  a  vehicle  on  one  of  the  two-dimensional  screens.  Therefore,  in  the  body  of 
the  JANUS(X)  function  to  send  this  message,  a  message  destined  for  NPSNET  called 


ctjget  vehjnove  mess  is  embedded.  This  message  includes  the  side  and  unit  number  of 
the  vehicle,  its  speed,  orientation  and  current  coordinates.  Using  the  segment_number 
provided  by  the  JANUS  (X)  simulation,  the  speed  and  orientation  (labeled  vehview)  of  the 
vehicle  are  retrieved  from  the  global  structures  Mnirsdara.5pegd[side][vehicle_number]  and 
d/recr.dvjew[side][vehicle_number]  respectively.  Using  the  side  and  vehicle  number  as 
indices,  NPSNET  can  adjust  the  location,  speed  and  direction  of  the  vehicle  in  the  three- 
dimensional  world. 

4.  Vehicle  Shots 

Just  as  with  initialization  of  the  vehicle  set,  JANUS(X)  does  not  send  any 
message  which  specifically  identifies  that  a  vehicle  fired  a  shot.  Therefore,  a  function  was 
written  to  write  this  message  to  NPSNET,  called  ct  send  veh  Jire.  This  message  sends  the 
force  side  and  vehicle  identification  number  for  both  the  shooter  and  the  intended  target. 
Upon  receipt  of  this  message,  NPSNET  will  render  a  muzzle  flash  for  the  vehicle  that  fired. 
Also,  a  red  or  blue  line  (depending  on  the  force  side  of  the  firer)  is  drawn  from  the  shooter 
to  the  target.  This  line  simulates  the  tracer  action  of  a  shot,  while  the  color  allows  the 
observer  a  quick  reference  to  who  fired  it.  The  ct  send  vehjire  message  function  is  called 
by  the  FORTRAN  function  drawfire.  Every  time  the  JANUS(X)  sub-program,  intactfor, 
indicates  that  a  vehicle  shot  its  weapon  it  calls  the  drawfire  function. 

5.  Artillery 

Just  as  with  vehicle  shots,  JANUS(X)  does  not  send  any  message  which 
specifically  identifies  that  artillery  was  fired.  So  again,  a  function  was  written  to  send  an 
artillery  message  to  NPSNET.  The  name  of  this  message  is  ct  send  arty,  and  it  sends  the 
X  and  y  coordinates  where  the  artillery  is  currently  landing.  When  this  message  is  received 
by  NPSNET,  an  artillery  explosion  is  rendered  at  the  coordinates  indicated.  The  artillery 
message  is  initiated  by  the  FORTRAN  function  drawarty.  The  JANUS(X)  sub-program, 
indfir.for,  upon  indication  of  an  artillery  shot,  calls  the  drawarty  function. 
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6.  Vehicle  Destruction 

The  death  or  destruction  of  a  weapon  system  in  the  JANUS(X)  combat  model  is 
simulated  by  simply  removing  its  icon  from  the  two-dimensional  screen.  This  removal  is 
executed  using  the  message  ct  delete  segment.  To  notify  NFS  NET  of  the  destruction  of  a 
vehicle,  a  message  to  NPSNET  was  embedded  in  the  function  ct  delete  segment.  This  new 
message  sends  the  force  side,  vehicle  identification  number,  grid  coordinates  and  the  final 
orientation  of  the  vehicle.  NPSNET  then  simulates  the  destruction  of  a  vehicle  by  halting 
it  and  displaying  an  orange  flame. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONCLUSIONS 

1.  Results 

Two  important  results  were  achieved  with  this  work.  First,  NFS  NET  was 
validated  as  a  flexible,  three-dimensional  simulation  platform  for  integration  with 
traditional  two-dimensional  models.  Second,  it  was  shown  that  a  traditional  two- 
dimensional  combat  model  can  be  successfully  displayed  in  three-dimensions.  This 
provides  new  life  to  systems  that  would  otherwise  rapidly  become  obsolete.  What  makes 
the  second  result  even  more  noteworthy  is  that  the  three-dimensional  display  is  achieved  at 
a  very  low  cost. 

2.  Applications 

Currently,  NPSNET  provides  the  JANUS(A)  combat  modelers  a  method  to 
verify  many  of  their  algorithms.  For  instance,  visibility  testing  algorithms  can  easily  be 
verified  by  moving  a  vehicle  to  a  prescribed  position  on  the  battlefield  and  actually 
analyzing  its  true  field  of  view.  Another  use  of  NPSNET :JANUS-3D  is  to  provide  the  war¬ 
fighter  operator  immediate,  realistic,  visual  feedback  of  an  ongoing  battle.  This  provides  a 
more  realistic  training  tool  for  the  operator,  as  opposed  to  merely  reading  the  synthesized 
data  printed  to  the  two-dimensional  JANUS(A)  screen.  Also,  NPSNET:JANUS-3D 
provides  the  combat  weapons  system  developer  the  ability  to  easily  visualize  a  new  weapon 
system.  The  developer  can  develop  appropriate  tactics  for  the  system,  and  test  different 
weapon  system  specifications  such  as  size,  shape  and  positioning  of  optical  devices  prior 
to  constructing  any  portion  of  the  system.  NPSNET:  JANUS-3D  is  an  excellent  After- 
Action  Review  (AAR)  tool.  With  this  tool,  the  instructor  possesses  the  capability  of  riding 
through  the  replay  of  an  actual  battle  and  providing  salient  observations  of  a  vehicle’s 
explicit  conduct  during  an  operation  —  stopping  and  starting  the  replay  as  required. 
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B.  RECOMMENDATIONS 

There  are  several  features  that,  if  added  to  NPSNET:JANUS-3D,  would  further 
enhance  the  realism.  First,  there  is  a  need  to  add  temporary  cultural  objects  such  as  mine 
fields  and  abatis.  Second,  when  operating  the  simulation  in  a  networked/real-time  mode, 
the  synchronization  between  the  clock-speed  of  NPSNET  and  JANUS(A)  is  often 
misaligned.  Because  of  this  lack  of  synchronization,  vehicles  appear  to  Jump  on  the  screen. 
Therefore,  a  method  to  synchronize  the  clocks  of  the  two  models  is  desirable. 

While  this  project  proved  that  two-dimensional  combat  models  can  be  displayed  in 
three-dimensions,  it  only  allows  the  user  to  be  an  “observer”  of  the  simulation.  The  next 
logical  step  is  to  allow  the  observer  to  become  an  “operator”  within  the  simulation.  The 
goal  is  to  have  the  actions  of  the  operator  within  the  three-dimensional  world,  be  used  as 
input  to  the  two-dimensional  model.  This  feature  would  allow  war-fighters  and  combat 
model  analysts  the  capability  to  test  new  ideas  quickly  and  conduct  multiple  “what  if’ 
operations  using  the  model. 

The  version  of  NPSNET  used  for  this  project  used  NPS  networking  formats, 
however,  there  is  a  working  version  of  NPSNET  that  utilizes  SIMNET  networking 
protocols.  A  DIS  version  is  also  planned.  When  work  is  complete,  the  NPSNET: JANUS- 
3D  connection  will  be  the  prototype  for  connecting  DoD  combat  models  to  the  DoD 
Defense  Simulation  Internet.  Likewise,  when  “two-way”  communication  between  the 
three-dimensional  simulation,  NPSNET,  and  the  two-dimensional  combat  model, 
JANUS(A),  is  established,  NPSNET  will  become  the  important  interface  between  other 
three-dimensional  combat  simulations,  such  as  SIMNET,  and  the  traditional,  two- 
dimensional  combat  models. 
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APPENDIX  A:  FILE  TRANSLATION  TECHNIQUES 


A.  FILE  TRANSLATION  FROM  VAX  TO  IEEE 

One  of  the  first  difficulties  encountered  when  attempting  to  implement  JANUS  data 
files  in  NPSNET  was  a  serious  compatibility  problem  between  the  two  systems.  NPSNET, 
written  in  the  C  programming  language,  is  run  on  the  Silicon  Graphics  IRIS  computers 
which  uses  the  UNIX  operating  system.  JANUS(A),  on  the  other  hand,  consists  entirely  of 
code  written  in  VAX-1 1  FORTRAN,  a  structured  Digital  Equipment  Corporation  (DEC) 
extension  of  standard  FORTRAN-77,  and  operates  on  the  VAX  family  of  computers 
utilizing  the  VMS  operating  system  [JANU  86]. 

Little-endian  machines,  such  as  the  VAX,  store  words  with  the  high-numbered  byte  as 
the  most  significant,  while  big-endian  machines,  such  as  the  IRIS,  have  the  low-ordered 
bytes  of  a  word  as  the  most  significant. 


Big-endian 


2 

3 

Dl 

Little-endian 


ID 

3 

2 

□ 

Figure  26:  Big-Endian  vs.  Little-Endian  Architectures. 


In  addition  to  the  byte  ordering  problems  of  the  two  different  machines,  there  is  also 
a  difference  in  the  way  floating  point  numbers  are  stored.  The  VAX  architecture  defines 
four  floating-point  formats.  The  only  one  that  the  JANUS  data  files  utilize  is  the  four-byte 
format.  There  also  are  tv'o  8-byte  formats,  D_Floating  and  G_Floating,  and  one  16-byte 
format,  H_Floating.  As  stated  above,  the  VAX  architecture  is  little-endian,  which  means 
that  bits  <7:0>  are  stored  in  the  first  byte,  bits  <15:8>  in  the  second,  bits  <23:16>  in  the 
third,  and  <3 1 :24>  in  the  fourth. 
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Figure  27:  VAX  Architecture,  Four-Byte,  Roating  Point  Format. 

This  is  a  sign-magnitude  representation,  with  the  sign  in  bit  <15>,  an  excess  128 
binary  exponent  in  bits  <14:7>,  and  a  normalized  24-bit  fraction  in  bits  <6:0>  and  <3 1 : 16>. 
An  exponent  value  of  0  and  a  sign  bit  of  0  are  taken  to  indicate  true  zero,  while  an  exponent 
value  of  0  and  a  sign  bit  of  1  indicates  a  reserved  operand  (results  in  a  reserved  operand 
fault  when  processed).  Exponent  values  of  1  through  255  indicate  true  binary  exponents  of 
-127  through  +127  [VAX  90]. 

This  known,  the  conversion  from  VAX  to  SGI  for  integers  simply  involves  a  reversal 
in  the  order  of  the  bytes.  The  conversion  for  floats  is  slightly  more  involved.  First,  Byte  1 
is  exchanged  with  Byte  2.  Then,  Byte  3  has  one  subtracted,  and  is  exchanged  with  Byte  4 
[BUHL  91].  An  example  of  the  C  code  to  accomplish  the  conversion  for  floats  follows: 
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This  is  function  vax_real_to_sgi_f loat .  It  accepts  a  vax 
formatted  float,  (as  an  unsigned  long  in  hex) ,  and  returns 
the  float  value  in  IEEE  format. 


/*  prototype*/ 

float  vax_real_to_sgi_f loat (unsigned  long) ; 


float  vax_real_to_sgi_f loat (unsigned  long  vax_real) 

{ 

union  VAXSTUFF 
{ 

unsigned  char  byte[4] ;  /*  array  of  four  bytes  used  for  */ 
float  ieee_float;  /*  this  is  the  returned  ieee  format  */ 
unsigned  long  vax_int;  /*  holds  the  vms  input  format  */ 

}; 

union  VAXSTUFF  indata; 
unsigned  char  temp; 


indata. vax_int  =  vax_real; 

/*  start  swapping  bytes  */ 
if  (indata. vax  int!=  00000000) 
{ 

temp  =  indata.byte[l]  -  1; 


else 

{ 

/*  a  0.0  is  a  0.0  in  any  format  */ 
temp  =  indata .byte [1]; 


indata. byte [1]  =  indata.byte[0]; 
indata. by te[0i  =  temp; 

temp  =  indata .byte [ 3 ] ; 
indata.byte[3]  =  indata. byte [2 ] ; 
indata,  byte  [2]  =  tertp; 

/*  this  is  your  answer  */ 
return  (indata. ieee  float); 

} 


Figure  28:  Example  Code  for  VAX  to  SGI  Float  Conversion 
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APPENDIX  B:  USER’S  GUIDE 


A.  INTRODUCTION 

This  appendix  provides  a  step-by-step  description  of  the  programs  and  procedures  that 
must  be  performed  to  create  the  three-dimensional  NPSNET:JANUS-3D  virtual  world  and 
run  the  simulation  in  scripted  and  real-time  modes.  This  appendix  is  divided  into  six 
sections: 

•  VAX  to  UNIX  file  translation 

•  Generation  of  three-dimensional  terrain 

•  Generation  of  a  script 

•  Operation  of  the  two-dimensional  replay  simulation 

•  Operation  of  NFS  NET  with  a  script 

•  Operation  of  NPSNET  and  JANUS(X)  in  a  networked,  real-time  mode 

Within  this  document,  all  files  and  directories  are  written  in  italics,  and  all  commands 
that  must  be  entered  at  the  key  board  are  written  in  bold. 

B.  VAX  TO  UNIX  FILE  TRANSLATION 

The  following  section  provides  a  description  of  the  programs  and  procedures  that 
translate  the  JANUS  binary,  terrain,  system,  force,  deploy,  and  post-processor  files  from  a 
VAX  to  Unix  format  Before  starting,  the  user  must  ensure  that  the  files  listed  above,  are 
copied  from  the  VAXA^MS  system  to  a  nine  inch  tape  using  the  VMS  copy  command. 
These  files  are  then  loaded  into  the  Unix  system  using  the  Unix  vmstp  command.  These 
files  must  be  copied  in  lis  exact  manner,  because  the  translation  programs  were  written  to 
accommodate  the  administrative  bytes  inserted  by  the  VAX  computer  during  the  copy 
process  (i.e.  the  block  and  record  delineation  bytes.). 

To  begin  the  file  translation  process,  copy  the  following  JANUS(A)  files  from  the  nine 
inch  tape  to  the  Inigravyllworkitracljanuslldmapstuffifiles  directory: 

•  terain###.dat 

•  system###.dat 
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•  force###,  dat 

•  dploy###.dat 

•  ppmove###.dat 

•  ppfirs###.dat 

•  ppmins###.dat 

•  pparty###.dat 

•  ppkils###.dat 

•  ppdtec###.dat 

1.  Translation  of  Terrain  File 

First,  run  the  program  readtrrn.  It  is  located  in  the  nigravyllworkitracljanusi 
Idmapstujf I  terrain  directory.  This  program  reads  the  JANUS(A)  file,  terainM#.dat,  from 
the  Ini  gravy!  Iworkl  trad januslldmapstujfifiles  directory,  and  converts  the  data  contained 
in  the  file  to  a  Unix  format.  The  converted  data  is  written  to  the  ASCII  files  ###.ele  (terrain 
elevation  data),  Mtt.riv  (river  location  data),  and  ###.road  (road  location  data),  which  are 
located  in  the  lnlgravy2lworkltracljanusl2dmapstuffl files  directory.  Additionally,  the 
header  file,  janus.h,  is  created  and  written  to  the  lnlgravyIlwork2lprattlsimnetlcoll2l 
headers  directory.  The  janus.h  file  contains  all  of  the  static  definitions  for  the  terrain 
database  such  as  the  size  of  the  map,  UTM  coordinates  for  the  lower-left  hand  comer  of  the 
map  and  the  resolution  value  for  each  grid  square.  All  other  programs  -  to  include 
NPSNET  —  use  the  definitions  found  in  Janus.h  during  execution. 

Usage:  readtrrn  ###,  where  ###  is  the  three  number  identifier  from  the 
terrain  file  terrainM^.dat. 

2.  Recompilation 

Once  the  terrain  file  is  translated  and  Janus.h  is  written,  all  programs  pertaining 
to  NPSNET:JANUS-3D  must  be  recompiled.  Therefore,  the  usei  .oust  go  to  the  directories 
listed  in  Figure  29  and  type  the  following  sequence  of  commands: 

>  rm  * .o 

>  make 
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Inigravyl/worldtracljanuslldmapstuffifiles 

/n/gravy2lwork/trac/janusl2dniapsniff/force 

lnlgravy2lworkltracljanusl2dmapstufflsystem 

lnlgravy2lworkltracIjanusl2dmapstujfldeploy 

lnlgravy2lworkltracljanusl2dmapstufflscript 

ln/gravy2/workltrac/janus/dirt/makeground 


Figure  29:  List  of  Directories  Requiring  Recompilation 

3.  Translation  of  the  System  File 

Next,  the  program  readsysfiles  is  executed.  It  is  located  in  the  nlgravy2lworkl 
tracljanusl2dmapstuff/system  directory.  This  program  reads  the  JANUS(A)  file, 
system##U.dat  from  the  lnlgravy2lworkltracljanusl2dmapstufflfiles  directory,  converts  the 
data  to  Unix  format  and  produces  the  ASCII  files  sysJorce.dat  (JANUS(A)  system  and 
weapons  information),  name.dat  (weapon  to  system  number  references),  and  cloud.dat 
(cloud  ceiling,  cloud  coefficients,  and  wind  speed).  These  files  are  also  written  to  the  Ini 
gravy2lworkltracljanusl2dmapstufflfiles  dkcctory. 

Usage:  readsysfiles  ###,  where  ‘###’  are  the  three  numbers  associated 
with  the  JANUS(A)  system  file,  systemM#.dat. 

4.  Translation  of  the  Force  File 

The  program  recutforce  is  executed  next.  It  is  located  in  the  nlgravy2 1  world  trad 
janusl2dmapstuff/force  directory.  This  program  reads  the  JANUS(A)  fSL",  force###. cUit 
from  the  Inlgra\ry2l work! trad janusl2dmapstuffl files  directory.  It  converts  the  data  to  Unix 
format  and  produces  three  ASCII  files  called  sysnames.dat  (matches  weapon  to  its  system), 
force.data  (matches  a  vehicle  to  its  side  and  system),  and  icontable.dat  (matches  a  two- 
dimensional  icon  to  a  vehicle).  These  files  are  written  to  the  Ini gravy2l work! trad janus! 
2dmapstufflfiles  directory. 

Usage:  readforce  ###,  where  ‘###’  are  the  three  numbers  associated  with 
the  JANUS(A)  force  file,  forceim.dat. 
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5.  Translation  of  the  Deployment  File 

The  program  readdeploy  is  executed  next.  It  is  located  in  the  nl gravy! I worki trad 
janusUdmapsti^ deploy  directory.  This  program  reads  the  JANUS(A)  file,  dploy#M.dat 
from  the  InlgravyHworkltradjanusUdmapstufflfiles  directory.  It  converts  the  data  to  Unix 
format  and  produces  the  ASCII  file  initunit.dat  (initial  locations  of  vehicles).  This  file  is 
written  to  the  InlgravyHworkltradjanusUdmapstufflfiles  directory. 

Usage:  readdeploy  ###,  where‘###’  are  the  three  numbers  associated  with 
the  JANUS(A)  deployment  file,  dployM^.dat. 

6.  Translation  of  Post-processor  Files 

The  program  readppfiles.c  is  executed  after  the  terrain,  force,  system  and 
deployment  files  are  translated.  It  is  located  in  the  nlgravyllworkltradjanusUdmapstuffl 
files  directory.  This  program  reads  the  JANUS(A)  files,  ppmove#M.dat,  ppfirs###.dat, 
ppminsUM.dat,  pparty###.dat,  ppkils#M.dat,  and  ppdtecM#.dat,  which  are  located  in  the 
Inlgravyllworkltradjanuslldmapstufflfiles  directory.  It  converts  the  data  to  Unix  format 
and  produces  the  ASCII  files  called  ppmove.dat,  ppfire.dat,  ppmines.dat,  pparty.dat, 
ppkills.dat,  and  ppdtec.dat  respectively.  These  files  are  written  to  the  Ini  gravy!  fworki  trad 
janusUdmapstuff! files  directory. 

Usage;  readppf  lies  ###,  where*###’  are  the  three  numbers  associated  with 
each  JANUS(A)  post-processor  files. 

C.  TERRAIN  GENERATION 

All  the  programs  used  to  generate  the  three-dimensional  terrain  are  located  in  the  Ini 
gravyHworkltradjanusIdirtlmakeground  directory.  These  programs  must  be  generated  in 
the  exact  order  specified  below.  Additionally,  generation  of  the  polygonized  terrain  is  both 
time  consuming  and  memory  consuming.  Most  files  can  be  deleted  once  all  of  the  terrain 
is  generated.  The  names  of  the  files  that  must  remain  are  listed  at  the  end  of  this  section. 
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Before  executing  any  programs,  erase  everything  in  the  directories  listed  in  Figure  30 
using  the  Unix,  rm  *  command. 


Inigravyllworkitracljanusidirticoverfiles 
Inlgravyllworkltracljanusldirtltextcoverfiles 
Inigravyllworkitracljanusidirtlelevfiles 
Ini gravyllworki  trad janusidirtitextelevfiles 
Inigravyllworkitradjanusidirtlobjectfiles 
Inlgravy2lworkltradjanusldirtltextobjec0les 
Inigravyllworkitradjanusidirtiquadfiles 
Ini  gravy!  IworkItradjanusIdirtI  textqmdfi  les 
Ini gravyHwork!  trad janusidirtiroadriverfiles 

Figure  30:  Terrain  Data  Directories 

Once  these  directories  are  clear  then  execute  the  following  programs  in  the  order 
listed: 

(1)  genbinaryelev;  This  program  reads  the  file  M#.ele  found  in  the  InJ 
gravyHworkltradjanusUdmapstufflfiles  directory,  and  creates  the  binary  elevation  file 
named  elev.bin.dat  in  the  Inlgravyllworkltradjanusldirtlelevfiles  directory. 

Usage:  genbinaryelev  ###,  where‘###’  are  the  three  numbers 
associated  with  the  file,  lt#ft.ele. 

(2)  make_tri_mesh:  This  program  reads  the  file  ItM.ele  found  in  the  Ini 
gravyHworkltradjanusUdmapstufflfiles  directory,  and  calculates  the  point  normals  for 
each  elevation  in  the  elevation  file.  It  then  writes  this  information  to  a  binary  file  named 
elev.mesh.dat  in  the  InlgfavyHworkltradjanusIdirtlelevfiles  director)'. 

Usage:  make_trl_me8h  ###,  where*###’  are  the  three  numbers 
associated  with  the  file,  IfM.ele. 

(3)  conv_elev2block_bin:  This  program  reads  the  file  #M.ele  found  in  the  / 
nlgravyH work! trad janusUdmapstuff! files  directory.  Each  elevation  is  then  rewritten,  in 
binary,  to  a  file  in  the  Ini  gravy! !  work!  trad janus!  dirt!  elevfiles  directory.  The  file  that  it  is 
written  to  corresponds  to  the  quadnode  in  which  it  is  located.  The  generic  name  for  these 
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new  elevation  files  is  elevXXXXZZZZ.dat,  where  XXXX  and  ZZZZ  are  the  quadnode 
indices  for  the  file. 

Usage:  conv_elev2block_bin 

(4)  janus2nps:  This  program  reads  the  file  ###.ele  found  in  the  Inigravyll 
workitracljanuslldmapstuffifiles  directory.  This  data  is  then  converted  to  polygonized 
terrain  data  and  converted  to  David  R.  Pratt  (NPSDRP)  data  format  [PRAT  92a].  The  new 
data  is  then  written  in  ASCII,  to  the  file  cover.dat,  found  in  the  InIgravyllworkItracljanusI 
dirtitextcoverfiles  directory. 

Usage:  janu82nps  ###,  where  ‘###’  are  the  three  numbers 
associated  with  each  file,  MU.ele. 

(5)  reverseroads:  This  program  reads  the  files  UM.road  and  M#.riv  found  in 
the  lnlgravy2lworkltracljanusl2dmapstufflfiles  directory.  These  files  contain  the 
coordinates  for  each  road  and  river  checkpoint.  These  coordinates  are  converted  to  the 
NPSNET  coordinate  system  and  rewritten  to  the  ASCII  files  road.dat  and  riv.dat, 
respectively.  Both  of  these  files  are  located  in  the  directory,  /nlgravy2lworkltracljanusldirtl 
roadriyfiles. 

Usage:  reverseroads  ###,  where  ‘###’  are  the  three  numbers 
associated  with  the  files,  ##U.nv  and  t^.road. 

(6)  makeroadfile:  This  program  reads  the  files  road.dat  and  riv.dat,  found  in 
the  /n/gravy2/work/trac/janus/dirt/roadriverfiles  directory,  and  creates  two  point  line 
segments  with  the  data.  This  new  information  is  then  written  to  the  ASCII  file  roads.dat 
found  in  the  /n/gravy2/work/trac/janus/dirt/roadriyfiles  directory. 

Usage:  makeroadfile 

(7)  makeroads:  This  program  reads  the  file  roads.dat  found  in  the  Inlgravy2l 
workltracljanusldirtlroadriverfiles  directory  and  converts  the  data  into  DRP  polygonized 
terrain  format.  This  new  information  is  then  written  to  the  ASCII  file  roadcover.dat  found 
in  the  lnlgravy2lworkltracljanusldirtlroadrivfiles  directory. 

Usage:  makeroads 
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(8)  maketrees:  This  program  reads  the  file,  M#.ele,  found  in  the  Inigravyll 
world  trad januslldmapsti^l files  directory  and  the  file  roadcover.dat  found  in  the  Ini 
gravyllworkitradjanusidirtiroadriyfiles  directory.  It  then  generates  the  locations  for  tree 
and  city  canopies,  and  stores  this  information  in  the  files  treeblock.dat  and  cityblock.dat 
respectively.  These  two  files  are  found  in  the  lnlgravy2lworkltradJanusldirtltextobJec files 
directory.  The  program  also  calculates  the  locations  for  individual  trees  and  buildings  and 
sorts  them  by  their  height/density  factors  into  the  files  cityl.dat  through  dty7.dat  and 
treeLdat  through  tree7.dat.  These  files  are  also  written  to  the  Ini  gravyll  world  trad janusi 
dirt! textobjec files  directory. 

Usage:  maketrees 

(9)  genblockcov:  This  program  reads  the  file,  cover.dat,  from  the  directory, 
Inigravyllworkitradjanusidirtitectcoverfiles,  and  the  file,  roadcover.dat,  firom  the 
directory,  Inigravyllworkitradjanusidirtiroadriyfiles.  The  elevation  data  from  these  files  is 
rewritten,  in  ASCII,  to  a  file  in  the  Inigravyllworkitradjanusidirtitextcoverfiles  directory. 
The  generic  name  for  these  new  elevation  files  is  coverXXXXZZZZtext.dat,  where  XXXX 
and  ZZZZ  are  the  quadnode  indices  for  the  file.  The  file  name,  that  the  data  is  written  to, 
corresponds  to  the  quadnode  in  which  it  is  located. 

Usage;  genblockcov 

(10)  conv_b!ockcov2bin;  This  program  uses,  as  input,  the  files  that  were 
produced  by  the  program  genblockcov.  The  generic  nartw  for  these  files  are 
coverXXXXZZZZtext.dat.  They  are  found  in  the  lnlgravy2lworkltracljanusldirtl 
textcoveifiles  directory.  The  program  rewrites  the  files  to  binary  formatted  files,  found  in 
the  lnlgravy2lworkltracljanusldirtlcoveifiles  directory.  The  new  generic  name  for  the  files 
is  coverXXXXZZZZbin.dat,  where  XXXX  and  ZZZZ  are  the  quadnode  indices  for  the  file. 

Usage;  conv_blockcov2bin 

(11)  genquadcov;  This  program  reads  the  files,  coverXXXXZZZZbin.dat, 
from  the  lnlgravy2lworkltracljanusldirtlcoverfiles  directory.  In  this  program,  the  polygons 
for  each  resolution  level  (high,  medium-high,  medium-low  and  low)  are  created,  then  each 
file  is  converted  into  a  quadtree  format.  Each  file  is  then  written  to  files  with  the  generic 


name  of  coverXXXXZZZZtextquad.dat  found  in  the  InIgravyllworkItracljanusIdirtI 
textquacffiles  directory. 

Usage:  genquadcov 

(12)  conv_quadcov2bin:  This  program  uses,  as  input,  the  files  that  were 
produced  by  the  program  genquadcov.  The  generic  name  for  these  files  are 
coverXXXXZZZZtextquad.dat.  These  files  are  found  in  the  InIgravyllworkItracljanusIdirtI 
textquadfiles  directory.  These  files  are  rewritten  to  binary  files  found  in  the  Ini  gravy!  IworkI 
tracljanusidirtiquadfiles  directory.  The  new  generic  name  for  the  files  is 
coverXXXXZZZZbinquad.dat,  where  XXXX  and  ZZZZ  are  the  quadnode  indices  for  the 
file. 

Usage:  conv_quadcov2bin 

(13)  genblockobj :  This  program  reads  the  files  treeblock.dat,  city  block.dat, 
treeLdat  through  tree7.dat,  and  cityl.dat  through  city7.dat,  all  from  the  Ini  gravy! !  work! 
tracljanusidirtitextobject  directory.  The  data  from  these  files  is  rewritten  to  ASCII  files  in 
the  Ini  gravy!  I  worki  trad janusldirtltextobjec0les  directory.  The  file  that  the  data  is  written 
to,  corresponds  to  the  quadnode  in  which  it  is  located.  The  generic  name  for  these  new 
elevation  files  is  objectXXXXZZZZtext.dat,  where  XXXX  and  ZZZZ  are  the  quadnode 
indices  for  the  file. 

Usage:  genblockobj 

(14)  conv_block_obj_to_bin:  This  program  uses,  as  input,  the  files  that  were 
produced  by  the  program  genblockobj.  The  generic  name  for  these  files  are 
obJectXXXXZZZZtext.dat.  These  files  are  found  in  the  InlgravyHworkltracljanusIdirtl 
textobjectfiles  directory.  The  program  rewrites  these  files  to  binary  files  and  places  them  in 
the  Ini  gravy!  lwork/tracljanusldirtlobjec0les  directory.  The  new  generic  name  for  the  files 
is  obJectXXXXZZZZbin.dat,  where  XXXX  and  ZZZZ  are  the  quadnode  indices  for  the  file. 

Usage:  conv_block_obj_to_bin 

Once  the  above  programs  are  completed,  all  files  may  be  erased  except  the  following: 

•  All  files  in  the  InlgravyHworkl tracljanusidirtiquadfiles  directory. 
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•  All  files  in  the  Inigravyllworkitracljanusidirtlobjectfiles  directory. 

•  The  file  elev.bin.dat  in  the  Inigravyllworkitracljanusidirtlelevfiles  directory 

•  The  file  elev.mesh.dat  in  the  Inigravyllworkitracljanusidirtlelevfiles 
directory 

At  this  point,  the  data  for  the  t-mesh  and  polygonized  terrain  is  created.  The  user  can 
now  write  the  script,  or  run  NFS  NET  in  the  real-time  mode. 

D.  SCRIPT  GENERATION 

To  generate  a  three-dimensional  script,  the  following  files  must  be  present  in  the  Ini 
gravy2lworkltracljanusl2dmapstufflfiles  diiectory: 

•  ppmove.dat 

•  ppfires.dat 

•  ppldlls.dat 

•  pparty.dat 

•  ppmines.dat 

Before  writing  the  script,  the  user  must  delete  all  files  from  the  lnJgravy2lworkltracl 
janusl2dmapstufflfiles/script_data  directory.  These  files  must  be  removed  because  many  of 
the  script  routines  ‘append’  information  to  files,  rather  than  ‘create’  new  files.  These  files 
can  be  erased  by  moving  to  the  /n/gravy2/work/trac/jani4sl2dmap5n^lfiles/script_data 
directory  and  typing  rm  *  at  the  prompt. 

Once  the  directory  is  empty,  the  script  is  written  by  executing  the  two  programs  listed 
below: 

(1)  makeinitialposfile;  This  program  is  located  in  the  lnlgravy2lworkltracljanusl 
dirt! make  ground  directory.  As  input,  it  uses  the  files  initunit.dat  and  sysnames.dat,  both 
located  in  the  lnlgravy2lworkltracljanusl2dmapstujflfiles  directory.  First,  this  program 
creates  the  file  janus\ehiclepos.dat  and  places  it  in  the  lnlgravy2lworkltracljanusldirtl 
textobjectfiles  directory.  This  file  contains  the  initial  positions  and  view  directions  for  each 
vehicle  used  in  the  script.  Also  the  program  creates  a  separate  file  for  each  vehicle  in  the  / 
nlgravy2lworkltracljanusl2dmapstuffJfiles/scriptjiata  directory.  The  generic  name  for 
these  files  is  newvehM###.dat,  where  the  first  #  represents  the  integer  value  for  the  side  of 
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the  vehicle  (one  =  blue,  two  =  red),  while  the  next  three  ###’s  represent  the  vehicle’s 
identification  number. 

Usage:  makeinitlalposfile 

(2)  writescript:  This  program  is  located  in  the  InIgravyllworkItracljanusI 
Idmapstuffiscript  directory.  It  uses  the  files  ppmove.dat,  ppfires.dat,  pparty.dat, 
ppkills.dat,  and  ppmines.dat,  as  discussed  above.  This  program  writes  a  series  of  files 
named  vehMM.dat,  and  realnewveh.dat  to  the  Inigravyllworkitracljanuslldmapstujfifilesi 
script  data  directory.  These  files  are  only  used  by  this  program  and  can  be  erased  upon  the 
conclusion  of  the  program’s  execution.  This  program  ultimately  produces  the  file 
janus_script.dat,  which  is  also  written  to  the  Inigravyllworkitracljanuslldmapstuffifilesi 
script  data  directory.  This  file  contains  the  script  that  is  used  by  NFS  NET: 

Usage:  writescript 

E.  Operation  of  the  Two*Dimensional  REPLAY  Program 

The  name  of  the  program  used  to  display  the  converted  two-dimensional  terrain, 
vegetation,  and  cultural  features  is  ‘REPLAY’.  In  addition  to  displaying  the  map,  this 
program  also  tests  the  converted  initialization  and  post-processor  files  by  means  of  a 
scripting  capability.  ‘REPLAY’  is  found  in  the  Ini gravy2l work! trad janusl2dmapsti0l 
terrain  directory. 

1.  Initialization  and  Start-Up  Procedures 

Before  starting  the  program,  all  of  the  necessary  files  must  be  converted,  and 
stored  in  the  lnlgravy2lworkltracljanust2dmapstufflfiles  directory.  These  files  include  the 
terrain,  initialization,  and  post-processor  files.  For  a  detailed  description  of  the  generation, 
names,  and  locations  of  these  files  (see  “VAX  TO  UNIX  FILE  TRANSLATION”  earlier 
in  this  Appendix). 

To  start  the  program,  simply  type  replay  ###.  *###’  is  the  three  digit  number 
corresponding  to  the  two-dimensional  digitized  terrain  map  being  used  in  the  scenario. 
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2.  Program  Manipulation 

The  two  major  functions  of  the  ‘REPLAY’  program  are  (1)  the  terrain  feature 
display  capability,  and  (2)  the  tactical  scenario  playback  capability. 

After  starting  the  program,  the  first  screen  to  appear  is  the  grey-scale  map  as 
shown  in  Figure  1.  As  illustrated  in  Figure  31,  clicking  and  holding  the  right  mouse  button, 
displays  the  Main  Menu.  To  render  the  different  terrain  features,  simply  slide  the  cursor 
into  the  Terrain  Features  Menu,  and  select  the  desired  feature.  An  example,  after 
selecting  cities,  vegetation,  roads,  and  rivers,  is  shown  in  Figure  2.  By  selecting  an  item 
from  the  menu  once  more,  each  terrain  feature  is  removed  from  the  display. 


MAIN  MENU 

TERRAIN  FEATURES 

Terrain  Features  ► 
Replay  Events 

Exit 

Show  Cities 

Show  Vegetation 

Show  Roads 

Show  Rivers 

Show  Trafficability 

Show  Micro  Roughness 
Show  River  Grids 

Show  Obstacles 

Show  Grid  Blow  Down 
Show  Grid  Fires 

Show  Chemical 

Show  Smoke 

Show  High  Explosives 

Figure  31:  REPLAY  Main  Menu  and  Terrain  Feature  Sub-Menu 
The  second  function  of  the  ‘REPLAY’  program  is  the  playback  capability.  To 
start  the  script,  click  on  the  Replay  Events  item  of  the  Main  Menu.  After  placing  the  Blue 
and  Red  force  vehicles  and  all  minefields  in  their  initial  positions,  the  script  of  the  battle  is 
immediately  started. 
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An  example  of  the  playback  program  is  shown  in  Figure  3.  Movement  events  are 
shown  by  moving  the  two-dimensional  icon  to  its  next  position.  Direct  fire  events  are 
drawn  with  straight  lines  —  blue  lines  represent  friendly  fire  and  red  lines  represent  enemy 
fire.  Indirect  fire  events  are  depicted  as  circles.  The  edges  of  the  circles  are  colored 
according  to  the  side  (red  or  blue),  and  the  interior  of  the  circle  is  painted  black  for  high 
explosive  or  white  for  smoke.  Smoke  rounds  remain  on  the  map  until  their  determined 
dissipation  time.  Destroyed  vehicles  are  changed  to  a  green  color,  and  remain  on  the  map 
at  that  position. 

Currently,  the  speed  in  which  the  script  executes  is  equal  to  the  recorded  game 
time.  Since  some  of  the  scenarios  are  over  two  hours  in  length,  this  requires  the  user  to 
watch  the  entire  battle,  when  the  last  30  minutes  may  be  the  only  interesting  part.  For  future 
work,  a  nice  feature  to  include  would  be  the  ability  to  speed  up  the  game  clock,  in  order  to 
move  quickly  to  a  point  of  interest.  A  menu  item  has  been  included  for  this,  which  will 
increase  the  clock  by  a  certain  time  factor  (see  Figure  32). 


Figure  32:  Replay  Events  Menu  and  Clock  Speed  Sub-Menu 
After  Replay  Events  is  executed,  the  script  can  be  reset  to  the  beginning  of  the 
battle  by  selecting  the  Reset  item.  Likewise,  the  user  can  exit  the  scripting  tool  and  return 


to  the  Main  Menu  by  selecting  Exit  Replay,  or  can  exit  the  entire  program  by  selecting 
Exit  Program  as  shown  in  Figure  32. 

F.  Operation  of  NPSNET:  JANUS-3D 

There  are  currently  two  different  methods  of  running  NPSNET:  JANUS-3D.  The  first 
is  a  Script  Mode,  and  the  second  is  a  Real-Time  Mode,  which  runs  concurrently  with 
JANUS(X)  over  a  network.  Different  compilations  are  required  for  JANUS-3D,  depending 
on  which  mode  is  chosen,  and  what  terrain  database  is  used.  This  section  discusses  the  steps 
necessary  to  compile  the  different  executable  programs,  followed  by  a  detailed  discussion 
of  the  operation  of  NPSNET;  JANUS-3D  in  the  two  different  modes. 

1.  NPSNET:  JANUS-3D  Compilation 

Currently,  NPSNET  can  be  compiled  in  three  different  modes  by  using  the  ‘C’ 
Programming  Language’s  #ifdef  command  during  compilation.  The  three  different 
variables  presendy  used  in  the  #define  command  are: 

•  NTC  ”  terrain  and  object  data  firom  the  National  Training  Center 

•  HTL  ”  terrain  and  object  data  from  Fort  Hunter  Liggett,  CA 

•  JANUS  -  terrain  and  object  data  generated  from  any  JANUS(A)  scenario 

The  option  chosen  decides  which  variable  must  be  defined  in  the  file  Ini  gravy  II 
work2lprattlsimnetlsdislcoll2lSYSTYPE.h.  Only  the  ‘JANUS’  option  will  be  discussed, 
since  the  NTC  and  HTL  versions  of  NSPNET  are  never  used  when  running  JANUS-3D. 
Besides  ensuring  that  the  SYSTYPE.h  file  is  properly  defined,  there  are  two  additional  files 
that  need  adjusting  in  order  to  compile  the  proper  version  of  JANUS-3D  -  janus.h  and 
files. h.  Both  of  these  files  are  found  in  the  Ini  gravy  llwork2lprattlsimnetlsdislcoll2lheaders 
directory. 

As  discussed  earlier, yaniw./i  is  created  by  the  program  readtrrn.  The  file  janus.h 
contains  the  static  definitions  that  pertain  to  a  particular  JANUS(A)  database.  When  a  new 
JANUS(A)  database  is  translated  for  use  with  NPSNET,  the  janus.h  file  that  is  created  for 
it  is  often  stored  under  a  temporary  name  for  future  use.  The  temporary  name  includes  the 
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word  ‘janus’,  followed  by  a  suffix  (e.g.  janus  Julda).  The  suffix  is  the  name  of  the  map 
used  in  the  terrain  database.  Because  the  janus.h  file  is  crucial  in  the  creation  of  the  proper 
three-dimensional  terrain  for  NFS  NET,  it  is  important  that  the  appropriate  version  is  named 
''janus.h”  during  the  compilation  process. 

The  second  hit,  files. h,  contains  all  of  the  #deflnes  for  every  file  that  is  written 
to  or  read  from  in  NFS  NET.  For  JANUS-3D,  several  options  are  available  in  files. h,  of 
which  currently  there  are  four:  (1)  Hunter  Liggett  Scripted  Version,  (2)  Fulda,  Germany 
Scripted  Version,  (3)  Fulda,  Germany  Real-Time  Version,  and  (4)  73  Easting  Scripted 
Version.  The  #defines  for  these  different  options  are  separately  grouped,  with  only  one 
being  readable  (uncommented)  at  a  time. 

After  SYSTYPE.h,  Janus.h  and  files. h  are  properly  formatted,  NFSNET  can  then 
be  compiled  and  run.  The  following  discussions  of  the  operation  of  NFSNET:  JANUS-3D 
are  based  on  the  assumption  that  the  user  is  familiar  with  the  operation  of  NFSNET,  thus 
only  the  JANUS-3D  peculiarities  are  discussed. 

2.  Operation  of  NFSNET:  JANUS.3D  in  Script  Mode 

Assuming  the  proper  version  of  the  program  was  compiled,  and  the  files  are  in 
the  proper  location,  start  JANUS-3D  in  the  scripted  mode  by  typing  npsnet  in  the  tn! 
gravy  I  IworkllprattlsimnetlsdisI colli  directory  (If  operating  on  an  SGI,  Indigo-Elan  type 
npsnet  t.).  When  initialization  is  complete,  and  NFSNET  is  started,  bring  up  the  two- 
dimensional  map  by  selecting  the  2d  Map  Window  item  of  the  Main  Menu  as  shown  in 
Figure  33.  This  will  display  the  entire  JANUS(A)  grey-scale  map,  in  the  upper-right  hand 
side  of  the  screen,  with  the  two-dimensional  iccn  symbols  in  their  initial  positions.  The 
viewer’s  location  will  be  in  the  observer-controller  vehicle.  Before  the  scripting  action  is 
started,  the  user  can  place  himself  inside  any  vehicle  by  picking  the  appropriate  icon  in  the 
2d  map  window.  Once  inside,  the  vehicle’s  position  and  viewing  angle  can  be  changed  with 
the  Space  Ball.  Later,  when  the  script  is  started,  each  of  the  vehicles  that  were  moved  will 
immediately  return  to  there  initial  location  and  orientation. 
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To  begin  the  script,  select  the  Play  Tracks  item  from  the  sub-menu.  Script 
Menu  as  depicted  in  Figure  33.  Like  the  two-dimensional  REPLAY  program,  the  speed  of 
the  script  runs  at  game  time,  and  cannot  be  increased.  However,  once  started,  the  script  can 
be  reset  by  selecting  the  Reset  Tracks  item  in  the  Script  Menu  as  shown  in  Figure  33. 
While  the  script  is  in  process,  the  viewer  can  take  semi-control  of  any  vehicle  with  the 
Space  Ball.  This  control  is  limited,  because  the  script  file  takes  precedence  over  the  user’s 
inputs.  In  other  words,  the  vehicle  will  jump  back  to  its  proper  location  and  orientation 
every  dme  the  script  tells  it  to. 


NPSNET  MAIN  MENU 

View  to  the  Tank 

Mesh  Mode  On 
Checkerboard  On 

Texture  Off 

Networking  On 

Reset  Networked  Vehicles 
Objects  On 

Hide  Other  Vehicles 

Show  Veh  Dashboard 

Hide  the  Info  Panel 

Script  Menu  ► 

Convoy  Menu  ► 

Fog  Menu  ► 

2d  Map  Window  ► 

SCRIPT  MENU 

Record  and  Play 
Play  Tracks 
Record  Tracks 
Stop  Tracks 
Reset  Tracks 

Screen  Snapshot 

Help  ► 

Exit 

Figure  33;  NPSNET  Main  Menu  and  Script  Sub-Menu 
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3.  Operation  of  NPSNET:  JANUS-3D  in  Real-Time  Mode 

To  run  JANUS-3D  in  a  real-time  mode,  two  different  programs  must  be  started; 
(1)  NPSNET,  in  the  network  mode,  and  (2)  JANUS(X),  from  an  IRIS  Workstation. 

NPSNET  must  be  started,  first,  by  typing  npsnet.  Once  NPSNET  is  running,  the 
networking  mode  must  be  turned  on  by  selecting  the  Networking  On  item  from  the  Main 
Menu  as  illustrated  in  Figure  33.  After  NPSNET  is  initialized  and  in  the  Networking  On 
or  ‘listening  mode’,  JANUS(X)  can  be  started  from  another  IRIS  Workstation. 

Before  beginning  JANUS(X),  the  user  must  be  logged  in  on  the  workstation  as 
TRAC.  This  is  because  the  .login  and  .cshrc  files  in  the  TPj\C  directory  contain  aliases  and 
path  designations  necessary  to  run  JANUS(X). 

To  start,  type  the  command  makejanwin.  The  program,  makejanwin,  is  a  shell 
script,  located  in  the  Inigravyllworkitracibin  directory  and  is  listed  in  Figure  34. 


wsh  -f  Screenl4  -m  80,80  -s  60,14  -p  700,260  -n  “RED  SIDE” 
wsh  -f  ScreenU  -m  80,80  -s  60,14  -p  700,10  -n  “BLUE  SIDE” 

xwsh  -fn  Screenl4  -max  120x120  -geom  92x32+14+600  -title  “JANUS  DRIVER”  -e  rlogin  libra 


Figure  34:  Makejanwin  Shell  Script 

Makejanwin  displays  three  separate  windows  at  the  bottom  of  the  screen.  The 
JANUS  DRIVER  screen  at  the  lower-left  comer  is  the  main  console  window,  from  which 
JANUS(X)  is  started.  The  main  console  window  is  remotely  logged  into  the  libra  file 
server,  because  JANUS(X)  requires  the  FORTRAN  ran-time  libraries  that  NPS  stores  on 
this  file  server.  The  other  two  windows  are  used  to  type  the  commands  necessary  to  display 
the  Red  and  Blue  side  screens,  and  are  titled  RED  SIDE  and  BLUE  SIDE,  respectively. 

In  the  RED  SIDE  window,  type  red.  This  will  display  the  window  for  the  red 
side,  which  can  be  positioned  anywhere  on  the  screen.  Typing  blue  in  the  BLUE  SIDE 
window,  will  duplicate  the  actions  taken  for  the  red  window.  These  commands,  red  and 
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blue,  are  aliases  which  are  defined  in  the  .login  file.  The  aliased  commands,  described  in 
Figure  35,  set  each  of  the  windows  to  a  ‘listening  mode’,  assign  a  port  number  (to  uniquely 
identify  the  window  for  packet  sending),  and  begin  the  program  xtest,  which  captures  the 
message  packets  and  calls  the  appropriate  graphic  functions. 

alias  blue  ’setenv  JANUS_L1STEN  20002;cd  ~trac/janus/sun;xtest  -x  font.O’ 
alias  red  ’setenv  JANUS_L1STEN  20001;cd  ~trac/janus/sun;xtest  -x  font.O’ 

Figure  35:  Example  of  Aliased  Commands  for  JANUS(X)  Initialization 
The  next  step  is  to  begin  the  JANUS(X)  model  in  the  JANUS  DRIVER  window. 
Type  xterm  at  the  TERM  =  (sun)  prompt  Then,  depending  which  IRIS  Workstation  is 
being  used,  type  in  the  command  runjsai_irisname,  with  irisname  corresponding  to  the 
workstation.  For  example,  if  the  model  is  being  displayed  on  gravy  1,  type  runjan_gravyl. 
These  commands  are  also  aliases  which  are  defined  in  the  ‘trac’  account’s  .login  file.  The 
aliased  commands,  as  shown  in  Figure  36,  produce  two  sending  stations  (one  blue  and  one 
red),  with  the  same  unique  port  numbers  as  the  listening  windows.  They  also  start  the 
program,  janus. 

alias  runjan_^ravyl  ’setenv  JANUS_TERMINAL_1  gravyl:20001; 

setenv  JANUS_TERMINAL_2  gravy 1:20002; 
cd  ~trac/janus/sun/janus/Programs;janus’ 

Figure  36:  Aliased  Command  to  Run  JANUS  on  Gravy  1  Terminal 
After  typing  the  runjan  command,  the  JANUS  DRIVER  window  will  prompt 
the  user  for  the  Scenario  Number  and  the  Run  Number  of  the  specific  JANUS(X)  scenario. 
After  entering  the  appropriate  numbers,  three  JANUS(X)  initialization  screens  will  be 
presented  in  succession.  Type  in  the  necessary  data  into  each  screen  followed  by 
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<ENTER>.  (NOTE:  The  <RETURN>  key  does  not  suffice,  <ENTER>  must  be  used). 
JANUS(X)  will  now  be  running  in  the  two  windows  marked  BLUE  SIDE  and  RED  SIDE. 

Once  the  two  screens  are  initialized,  the  JANUS(X)  grey-scale  map,  in  the  upper- 
right  hand  side  of  the  NPSNET  screen,  will  render  the  two-dimensional  icon  symbols  in 
their  initial  positions.  As  in  the  scripted  mode,  these  vehicles  can  be  entered  by  picking  the 
appropriate  icon  from  the  2d  map.  Once  the  real-time  link  is  started,  any  altered  vehicles 
are  returned  to  their  initial  positions  and  orientations. 

To  start  the  real-time  model,  select  the  EXIT  item  from  both  the  BLUE  SIDE  and 
RED  SIDE  windows  as  depicted  in  Figure  37.  The  JANUS  DRIVER  window  will  prompt 
the  user  to  press  <RETURN>.  After  pressing  <RETURN>,  the  real-time  version  of 
JANUS-3D  is  started.  While  the  real-time  battle  is  in  process,  the  viewer  can  take  semi¬ 
control  of  any  vehicle  with  the  Space  Ball,  but  loses  control  whenever  a  vehicle  receives  a 
message  from  the  network. 

To  end  the  real-time  simulation,  select  the  ADMIN  item  from  both  the  BLUE 
SIDE  and  RED  SIDE  windows  as  shown  in  Figure  37.  The  JANUS  DRIVER  window  will 
display  the  Admin  Menu.  Selecting  the  EJ  item  (End  Janus)  will  stop  JANUS(X).  When 
JANUS(X)  is  ended,  NPSNET  will  continue  updating  vehicle  positions  according  to  their 
last  speed  and  location.  To  clear  the  NPSNET  screen,  select  the  Reset  Networked  Vehicles 
item  from  the  NPSNET  Main  Menu.  Then,  if  needed,  the  JANUS(X)  model  can  be 
restarted  without  having  to  restart  NPSNET. 
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Figure  37:  Example  of  the  RED  SIDE  JANUS(X)  Screen 
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